From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3E3D93B29D for ; Wed, 20 Sep 2023 04:32:41 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id 0E6C71ACCAB; Wed, 20 Sep 2023 01:32:40 -0700 (PDT) Date: Wed, 20 Sep 2023 01:32:40 -0700 (PDT) From: David Lang To: Alexandre Petrescu cc: starlink@lists.bufferbloat.net In-Reply-To: <66313713-d88b-44f8-ae66-07444cf25311@gmail.com> Message-ID: <32sn6qp6-0438-7378-8428-porsnnq72q09@ynat.uz> References: <4p4n2226-p71p-882p-q83r-p81psp056228@ynat.uz> <66313713-d88b-44f8-ae66-07444cf25311@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="228850167-852891400-1695198760=:15407" Subject: Re: [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2023 08:32:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --228850167-852891400-1695198760=:15407 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT if you have multiple upstream links you can use (from one or different ISPs) you have to have smarts on your side to decide what link to have. If you are a big enough player (or have been around long enough), you can do BGP peering with them like a friend of mine has at his house. The rest of us need something to monitor the links and decide how to NAT and route the traffic. mwan3 can do this via policy routing in the linux kernel. This works with ISPs that aren't going to allow you to send them BGP routing updates (and remember, the vast majority of ISPs don't even allow you to run servers or get a static IP address, exactly the same as Starlink's normal user account) so your wish of not having to have software on your side and have things 'just work with multiple ISPs' isn't a reality, even before you include space based systems. Without having BGP routing, you cannot mix traffic for a single flow over multiple ISPs (and even with BGP, it's seldom a good idea to do so) mwan3 is free and available on OpenWRT, which is the basis for most commercial routers, the headache with it is figuring out what the correct policy is for you. In the simple case of a wired ISP and a cell backup (that's very expensive to run), the logic is simple, use the wired connection if you can, falling back to cell only when you can't. They may even be using mwan3, you wouldn't know (they could also be using an ugly pile of shell scrips for the limited use case) with location services (GPS, Galileo, etc.) the receivers are not mixing the signals together, they are running a separate location calculation for each system and mixing the resulting calculation together. The biggest reason for there being three major locations services is the govermental reluctance to have something as critical as this under the control of someone else, so those political organizations that can afford it (US, EU, and Russia) each maintain their own. A second reson is that a monoculture where everything is the same and stagnent to maintain compatibility is a very bad idea. I'm still looking for a reason why a system like Starlink should be treated any differently than your local cable/phone/cell/wireless ISPs and needs to do anything beyond the same IP 'dial tone' (or limited version of it) that they all currently provide. Solve the problem with the easier to deal with terrestial ISPs fist before demanding that space based systems do 'something' to integrate better. There's nothing available to integrate with. David Lang On Wed, 20 Sep 2023, Alexandre Petrescu via Starlink wrote: > Date: Wed, 20 Sep 2023 10:09:03 +0200 > From: Alexandre Petrescu via Starlink > Reply-To: Alexandre Petrescu > To: starlink@lists.bufferbloat.net > Subject: Re: [Starlink] Main hurdles against the Integration of Satellites and > Terrestial Networks > > > Le 19/09/2023 à 17:15, David Lang via Starlink a écrit : >> 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. > > Yes, it is a good idea to have a router that aggregates all traffic of > several ISPs at home.  I do not know mwan3 in particular, but as you > mention it, I think it can achieve a sort of load balancing between > several ISPs plugged into a same box at home. > > That can be achieved indeed thanks to the fact that all these ISPs offer > IP connectivity. > > But there can be more to it than that. > > One problem is IPv6, but I will discuss that separately. (is mwan3 > supporting pure IPv6?) > > One of the immediate advantage of these ISPs interworking would be that > one would not need to install mwan3 at home. > > Another advantage would be that of the customer who benefits from better > pricing schemes.  A starlink operator could offer services to a space, > infrastructure-less, MVNO (so to say) who would offer more competitive > prices to end user. > > Another: mwan3 could (probably?) mix together the high bandwidth offered > by e.g. Viasat with a lower latency offered by Starlink; probably > transport layer needs to be involved, and I am not sure mwan3 acts at > transport layer.  And, there again, if Viasat was plugged into Starlink > then that aggregation would not be needed to be done by a ground user > (mwan3). > > A similar situation happened with boxes from ISPs who mixed together > ADSL input with 4G input.  Initially, it was end users who proposed the > technique and then some ISPs migrated that functionality into ISP boxes > - the end user is no longer bothered by the mixing. > > A similar situation can be witnessed in the localisation domaint (GPS, > Galileo, etc.).  There, end user devices also mix together signals to > obtain better localisation - take advantage of more sats in view, better > acquisition times, more precision.  But that brings in more complexity > to end user - there are so many variants to choose from (GPS+Galileo, > GPS+Beidou, etc.), and no single end user device mixes all of them - and > also brings in more energy consumption to end user.  If the localisation > constellations were plugged into each other then end users would benefit > from less complex devices, less energy consumption. > > Alex > >> >> 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 >>>> To: Alexandre Petrescu >>>> Cc: Hesham ElBakoury , David Lang >>>>     ,  Dave Taht via Starlink >>>>     , 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 >>>> [...] >>>>> >>>>>> 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 >>>>>> > 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 >>>>>> >>>>> > >>>>>>>>> Reply-To: Alexandre Petrescu >>>>> > >>>>>>>>> To: 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 >>>>>> >>>>>>>>> https://lists.bufferbloat.net/listinfo/starlink >>>>>> >>>> >>> _______________________________________________ >>> Starlink mailing list >>> Starlink@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/starlink >> >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --228850167-852891400-1695198760=:15407--