From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 974F73B2A4 for ; Mon, 18 Sep 2023 21:08:48 -0400 (EDT) Received: by mail-vs1-xe36.google.com with SMTP id ada2fe7eead31-4524dc540c7so1137569137.0 for ; Mon, 18 Sep 2023 18:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695085728; x=1695690528; darn=lists.bufferbloat.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4HhPmT0Xi6FbRKbzVQuEUz+a+Ni2+Io/7iLkl5kqGL8=; b=keLv8C06hfxU+pRcCz4lP5uCCG4pokm6u4XFBPidT//AeDqwsOFhmjguYRUOOWuDZl J1KpOoSADZyk696h7Nb4xZ42Zo8kDksMie4dOZCUf4uPc2vRNU52PCK2JhK9ugEbZfDF TjuZHZfX8RTyNMdjlYFl5MpTb8ZmZ/kXvIlXpW4LbJicWeOrOwtpTInXkJqsZr7o+AAr /Rm46eU0JR50mGjEJikrycQdNmJELJoiz8q3cvG7T86OazpJzWlYAj0Y92Jw1QzqK5vo IJJP2cmDZMx/YhXOYIPxybMATqEZdbSdeVe5joEMLOI6ahT1z5KQOW61DDRDirwN2Quc A7zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695085728; x=1695690528; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4HhPmT0Xi6FbRKbzVQuEUz+a+Ni2+Io/7iLkl5kqGL8=; b=RglTfE56aDiFwuq7iOSAzt4pOrjkX0yqMdNh1pNOMC8OjMT3WOj/5kLq3xdPmEn7t/ +c4VgeQIyHv6N6nWv9M6nQYNNy5Z3DUaUVifKpkTMPOU/hd26XBjDl2CO5fIyWeyGUcT uU21Rrb91lUDf3PNCuLUH9h4q014TmHQCbEnLe0TL7VhPEzyn9FSmkBIbcZJwo3Lo4MM zpitxGzwY6WzzAWA996uSxFbLcl9w2X5nT2Y6vieek4Po3Lnov1yB9zso8xCRPNomkqX Gpx1WoZxJfbTVpdSZa7SobQ9HEWVn4H25RTQEG4chcIb4aFz8sD/hhIcDgCTKKuXZG5G R6Jg== X-Gm-Message-State: AOJu0YybUvBy/q1B9up7u4i5TXKwfmocA+Fqzf995gJ7CdinO0VolS2R Ywl7qr3QDM2JOzIFgJjCL8Fj89kOUyjOl7kpLm4= X-Google-Smtp-Source: AGHT+IHfxMlRyf1rx//jvLb6ngZNi80bJ1oexxkOTvZq7zJlqnbY5WVEOfzjhcSlTuAfU3otBHzxWyJJg3e9kSoeVu4= X-Received: by 2002:a67:fd42:0:b0:44d:4a41:8945 with SMTP id g2-20020a67fd42000000b0044d4a418945mr8435112vsr.8.1695085727850; Mon, 18 Sep 2023 18:08:47 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <6280o672-906n-12s4-sn22-531648p5253s@ynat.uz> From: Jorge Amodio Date: Mon, 18 Sep 2023 20:08:13 -0500 Message-ID: To: David Lang Cc: Hesham ElBakoury , Alexandre Petrescu , Dave Taht via Starlink , sat-int@ietf.org Content-Type: multipart/alternative; boundary="000000000000ac258e0605abe6bc" X-Mailman-Approved-At: Tue, 19 Sep 2023 16:59:11 -0400 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: Tue, 19 Sep 2023 01:08:48 -0000 --000000000000ac258e0605abe6bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe that a better definition and characterization of "NTN" would be appropriate. 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. My .02 Jorge On Mon, Sep 18, 2023 at 8:01=E2=80=AFPM 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 requir= e > standardization of the in-space signals and protocols) > > I may be missing something at this point (I don't claim to be a networkin= g > 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 wit= h > >> dynamic > >> addressing, no inbound connections, no BGP peering, etc. No reason tha= t > >> 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 t= he > >>>> 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 route= rs > >> 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> > >>>>> 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 =C3=A0 01:32, Ulrich Speidel via Starlink a =C3=A9cri= t : > >>>>>> 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, yo= u > >>>>>>> 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 impa= ct > >> 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 3G= PP > >>>>> 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 /6= 4 > >>>>> 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 > --000000000000ac258e0605abe6bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I believe that a better definition and characteri= zation of "NTN" would be appropriate.

NT= N can represent a yuuuuuuuuge space... networking to Proxima Centauri could= be considered NTN, but I bet you will have a completely different set of c= hallenges than LEO, MEO, GEO, etc.

My .02
Jorge


On Mon, Sep 18, 2023 at 8:01=E2=80=AFPM David= Lang <david@lang.hm> 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 <= br> terrestrial tunnels (think frame relay networks that overlay a virtual netw= ork
on top of the physical network, encrypted or not). There probably are new <= br> routing protocols that will handle these better than current ones, but I se= e
that a matter of such links being more common, rather than being fundementa= lly
different.

I do see that in the future, if/as information about the in-space routing <= br> 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 fo= r
'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 network= ing
expert, but I'm seeing buzzwords here, but not an explination of why no= rmal 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 <david@lang.hm> wrote:
>
>> On Mon, 18 Sep 2023, Hesham ElBakoury wrote:
>>
>>> Given the discussions in this email thread, what IETF should s= tandardize
>> in
>>> priority order=C2=A0 for the integrated NTN terrestrial networ= ks?
>>
>> 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 comp= uter
>> with a
>> link to each of them can serve as a gateway (and this included pro= prietary
>> modems that were not compatible with anything else, the network di= dn'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 c= onsumer
>> dishes)
>>
>> I'll turn the question back to you, what is the problem that y= ou 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 conn= ected to the
>>>> satellites (there's even a status page and controls, s= towing 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
>>>>
>>>>=C2=A0 =C2=A0On Sun, 17 Sep 2023, Alexandre Petrescu via St= arlink wrote:
>>>>
>>>>> Date: Sun, 17 Sep 2023 19:21:50 +0200
>>>>> From: Alexandre Petrescu via Starlink <starlink@lists.buff= erbloat.net>
>>>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>>>> To: starlink@lists.bufferbloat.net
>>>>> Subject: Re: [Starlink] Main hurdles against the Integ= ration of
>>>> Satellites and
>>>>>=C2=A0 =C2=A0 =C2=A0 Terrestial Networks
>>>>>
>>>>>
>>>>> Le 16/09/2023 =C3=A0 01:32, Ulrich Speidel via Starlin= k a =C3=A9crit :
>>>>>> 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 o= r cable changes, you
>>>>>>> can plug it directly into a router.
>>>>>>
>>>>>> We've done that with the Yaosheng PoE Dishy ad= apter - actually plugged
>>>>>> a DHCP client straight in - and it "works&quo= t; 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 th= e DISHY, or
>>>>> whether it is on the ground network of starlink, i.e. = the reply to DHCP
>>>>> request comes after 50ms, or after 500microseconds (ti= mestamp
>> 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=C2=A0 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 cellu= lar networks
>> since
>>>>> they appeared.=C2=A0 Nowadays the DHCP behaviour is ve= ry complex in a 3GPP
>>>>> network; even in a typical smartphone there are intric= acies about where
>>>>> and how the DHCP client and server works. With it come= s the problem of
>>>>> /64 in cellular networks (which some dont call a probl= em, but I do).
>>>>>
>>>>> So, it would be interesting to see whether starlink ha= s 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 IPv= 6 that is, or
>>>> not?).
>>>>>
>>>>> Alex
>>>>>
>>>>> _______________________________________________
>>>>> Starlink mailing list
>>>>> Starlink@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/li= stinfo/starlink
>>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listin= fo/starlink
>>>>
>>>
>--
Sat-int mailing list
Sat-int@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sat-int
--000000000000ac258e0605abe6bc--