From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D059E3B2A4 for ; Thu, 21 Sep 2023 08:37:26 -0400 (EDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 38LCbKQ2038077; Thu, 21 Sep 2023 14:37:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 27FC9206868; Thu, 21 Sep 2023 14:37:20 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 11E76206828; Thu, 21 Sep 2023 14:37:20 +0200 (CEST) Received: from [10.8.32.70] (is156570.intra.cea.fr [10.8.32.70]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 38LCbJtJ037816; Thu, 21 Sep 2023 14:37:19 +0200 Message-ID: <4956a218-331a-4053-a49a-846ce6638163@gmail.com> Date: Thu, 21 Sep 2023 14:37:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: fr To: Jorge Amodio , David Lang Cc: Hesham ElBakoury , Dave Taht via Starlink , sat-int@ietf.org References: <2d05e701-7556-8ae4-122c-e2f2d23feff2@gmail.com> <4o116qp9-6108-91r8-pn91-o37o6629npqo@ynat.uz> <2012b68c-2e15-4b5c-b36b-3b1d7eff12b4@gmail.com> <0q3n1sp5-09r5-5pqn-3p9p-opq883305s1s@ynat.uz> <340fd78d-39eb-e9af-c15a-7ca87b173e4e@auckland.ac.nz> <40da3b55-38ad-4e02-8c58-afea2bd02279@gmail.com> <2sp89904-o460-976s-4rsq-55nn6ps84464@ynat.uz> <6280o672-906n-12s4-sn22-531648p5253s@ynat.uz> From: Alexandre Petrescu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Starlink] [Sat-int] 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: Thu, 21 Sep 2023 12:37:27 -0000 Le 19/09/2023 à 03:08, Jorge Amodio a écrit : > > I believe that a better definition and characterization of "NTN" > would be appropriate. True. > NTN can represent a yuuuuuuuuge space... networking to Proxima > Centauri could be considered NTN, but I bet you will have a > completely different set of challenges than LEO, MEO, GEO, etc. I'd look at where and how 'NTN' term originated. I believe it was at ITU several years ago that it was coined, even though I might be wrong. But in recent years it is used extensively at 3GPP. The way in which 3GPP uses this term 'NTN' makes think very much of a HAP (high-alti platform), or maybe one or two satellites, maybe at MEO or GEO orbits, but LEO is also in the picture. The examples that could approach that 'NTN', without being 'NTN', are the recent smartphones huawei mate60 pro on a GEO sat in a set of 3, but the iphone 14 and 15 is via LEO sats globalstar; none of the two are 'NTN'-labelled even though they are certainly 3GPP devices. Proxima Centauri: before that, I suppose they'll put 3GPP bases stations and user equipment on the Moon and on Mars, if not on a comet. For the moment it's not called 'NTN' but NTN does make sense indeed, because it's non-terrestrial. Alex > > My .02 Jorge > > > On Mon, Sep 18, 2023 at 8:01 PM David Lang > wrote: > > On Mon, 18 Sep 2023, Hesham ElBakoury wrote: > >> My understanding is that for integrated NTN and Terrestrial > network we may >> need new or enhanced routing protocols. There are many > publications in this >> area. > > I don't see how starlink hops have to be treated any differently > than terrestrial tunnels (think frame relay networks that overlay a > virtual network on top of the physical network, encrypted or not). > There probably are new routing protocols that will handle these > better than current ones, but I see that a matter of such links being > more common, rather than being fundementally different. > > I do see that in the future, if/as information about the in-space > routing becomes more open (and I strongly suspect, stabilizes more) > that there will be more that can be done, and at some point it may > even make sense to allow for 'peering' between satellites from > different providers (which would require standardization of the > in-space signals and protocols) > > I may be missing something at this point (I don't claim to be a > networking expert, but I'm seeing buzzwords here, but not an > explination of why normal IP routing isn't sufficient. > > David Lang > >> I suggest that you discuss your view in int-sat email list >> (copied) >> >> Thanks Hesham >> >> On Mon, Sep 18, 2023, 5:31 PM David Lang > wrote: >> >>> On Mon, 18 Sep 2023, Hesham ElBakoury wrote: >>> >>>> Given the discussions in this email thread, what IETF should > standardize >>> in >>>> priority order for the integrated NTN terrestrial networks? >>> >>> I don't see why you need to do any particular standardization to > integrate >>> things like starlink into terrestrial networks. >>> >>> Just like IETF didn't need to standardize ethernet/token >>> ring/arcnet/modems to make them compatible with each other. They >>> all talk IP, and a > computer >>> with a link to each of them can serve as a gateway (and this >>> included > proprietary >>> modems that were not compatible with anything else, the network > didn't >>> care) >>> >>> Starlink is 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) >>> >>> I'll turn the question back to you, what is the problem that you > think is >>> there that needs to be solved? >>> >>> 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 > >>>>> >>>> >> -- > Sat-int mailing list Sat-int@ietf.org > https://www.ietf.org/mailman/listinfo/sat-int > >