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

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

[Hesham ElBakoury]

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

Here is a report which summarizes the outcome of the last Satellites
conference  [
https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
]

The report highlights the two main hurdles against the integration of
satellites and terrestrial networks: standardization and business model.

"*Most of the pushback against closer integration of terrestrial wireless
and satellite networks revolved around standardization. This may just be
growing pains and it likely reflects the relative positions of wireless and
satellite along the maturity curve, but some of the speakers were arguing
against standardization. The basis of this argument was that the mobile
industry only understands standards, but the satellite industry is
currently differentiating based on custom systems and capabilities. The
feeling was that the satellite industry had focused on technology and not
regulations or standards and changing that course would not be helpful to
the industry in the short term. Timing is important in this analysis
because almost everyone agreed that at some point, standardization would be
a good thing, but the concern was the best way to get to the point in the
future. The other interesting argument against closer integration between
wireless and satellite had to do with the business model. Several speakers
questioned where the customers would go as terrestrial and non-terrestrial
networks become more integrated. The underlying issues seemed to include
who is responsible for solving network issues and perhaps more importantly,
who recognizes the revenue. These issues seem, perhaps a bit
simplistically, to be similar to early wireless roaming issues. While these
issues created turbulence in the wireless market, they were solved and that
is probably a template to address these challenges for the wireless and
satellite operators."*

Comments?

Hesham

[-- Attachment #2: Type: text/html, Size: 2328 bytes --]

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

[Alexandre Petrescu]

Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
> Here is a report which summarizes the outcome of the last Satellites 
> conference  
> [https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up]
>
> The report highlights the two main hurdles against the integration of 
> satellites and terrestrial networks: standardization and business model.
>
> "/Most of the pushback against closer integration of terrestrial 
> wireless and satellite networks revolved around standardization. This 
> may just be growing pains and it likely reflects the relative 
> positions of wireless and satellite along the maturity curve, but some 
> of the speakers were arguing against standardization. The basis of 
> this argument was that the mobile industry only understands standards, 
> but the satellite industry is currently differentiating based on 
> custom systems and capabilities. The feeling was that the satellite 
> industry had focused on technology and not regulations or standards 
> and changing that course would not be helpful to the industry in the 
> short term. Timing is important in this analysis because almost 
> everyone agreed that at some point, standardization would be a good 
> thing, but the concern was the best way to get to the point in the 
> future. The other interesting argument against closer integration 
> between wireless and satellite had to do with the business model. 
> Several speakers questioned where the customers would go as 
> terrestrial and non-terrestrial networks become more integrated. The 
> underlying issues seemed to include who is responsible for solving 
> network issues and perhaps more importantly, who recognizes the 
> revenue. These issues seem, perhaps a bit simplistically, to be 
> similar to early wireless roaming issues. While these issues created 
> turbulence in the wireless market, they were solved and that is 
> probably a template to address these challenges for the wireless and 
> satellite operators."/
> /
> /
> Comments?


It is an interesting report.

For standardisation standpoint, it seems SDOs do push towards 
integration of 5G/6G and satcom; there are strong initiatives at least 
at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But 
these are SDOs traditionally oriented to land communications, rather 
than space satcom.

I wonder whether space satcom traditional SDOs (which ones?) have 
initiated work towards integration with 5G/6G and other land-based Internet?

Alex

>
> Hesham
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

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

[Inemesit Affia]

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

With the existence of solutions like OpenMTCProuter, SDWAN, policy based
routing or any solution in general that allows combination in a sense of
any number of IP links, I really don't see a point for specific solutions.
Can anyone enlighten me?

For home users an issue may be IP blocks for certain services like Netflix
when the egress is out of a VPN or cloud provider richer than a residential
provider

On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
starlink@lists.bufferbloat.net> wrote:

>
> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
> > Here is a report which summarizes the outcome of the last Satellites
> > conference
> > [
> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
> ]
> >
> > The report highlights the two main hurdles against the integration of
> > satellites and terrestrial networks: standardization and business model.
> >
> > "/Most of the pushback against closer integration of terrestrial
> > wireless and satellite networks revolved around standardization. This
> > may just be growing pains and it likely reflects the relative
> > positions of wireless and satellite along the maturity curve, but some
> > of the speakers were arguing against standardization. The basis of
> > this argument was that the mobile industry only understands standards,
> > but the satellite industry is currently differentiating based on
> > custom systems and capabilities. The feeling was that the satellite
> > industry had focused on technology and not regulations or standards
> > and changing that course would not be helpful to the industry in the
> > short term. Timing is important in this analysis because almost
> > everyone agreed that at some point, standardization would be a good
> > thing, but the concern was the best way to get to the point in the
> > future. The other interesting argument against closer integration
> > between wireless and satellite had to do with the business model.
> > Several speakers questioned where the customers would go as
> > terrestrial and non-terrestrial networks become more integrated. The
> > underlying issues seemed to include who is responsible for solving
> > network issues and perhaps more importantly, who recognizes the
> > revenue. These issues seem, perhaps a bit simplistically, to be
> > similar to early wireless roaming issues. While these issues created
> > turbulence in the wireless market, they were solved and that is
> > probably a template to address these challenges for the wireless and
> > satellite operators."/
> > /
> > /
> > Comments?
>
>
> It is an interesting report.
>
> For standardisation standpoint, it seems SDOs do push towards
> integration of 5G/6G and satcom; there are strong initiatives at least
> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
> these are SDOs traditionally oriented to land communications, rather
> than space satcom.
>
> I wonder whether space satcom traditional SDOs (which ones?) have
> initiated work towards integration with 5G/6G and other land-based
> Internet?
>
> Alex
>
> >
> > Hesham
> >
> > _______________________________________________
> > 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
>

[-- Attachment #2: Type: text/html, Size: 4639 bytes --]

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

[David Lang]

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

Exactly my thoughts (I haven't downloaded and read the full report yet). What 
are they looking to do with this 'integration'? I can integrate my starlink just 
like any other ISP.

or are they looking at the 'cell phones to orbit' functionality thats due to 
roll out very suddently

or are they looking for "intergration" as another way to say "force SpaceX to 
open the specs for Starlink and allow other user terminals to interact with the 
Starlink satellites?

The cynic in me says it's the latter.

long term it may make sense to do this to some degree, but we are WAY too early 
to define "Interoperability Standards" and block people from coming up with 
better ways to do things.

the Apple vs SpaceX cellphone-to-satellite have completely different ways of 
operating, and who wants to tell all the Apple people that their way isn't going 
to be the standard (or worse, that it is and they have to give everyone else the 
ability to use their currently proprietary protocol)

David Lang

On Wed, 30 Aug 2023, Inemesit Affia via Starlink wrote:

> With the existence of solutions like OpenMTCProuter, SDWAN, policy based
> routing or any solution in general that allows combination in a sense of
> any number of IP links, I really don't see a point for specific solutions.
> Can anyone enlighten me?
>
> For home users an issue may be IP blocks for certain services like Netflix
> when the egress is out of a VPN or cloud provider richer than a residential
> provider
>
> On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>>
>> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>>> Here is a report which summarizes the outcome of the last Satellites
>>> conference
>>> [
>> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
>> ]
>>>
>>> The report highlights the two main hurdles against the integration of
>>> satellites and terrestrial networks: standardization and business model.
>>>
>>> "/Most of the pushback against closer integration of terrestrial
>>> wireless and satellite networks revolved around standardization. This
>>> may just be growing pains and it likely reflects the relative
>>> positions of wireless and satellite along the maturity curve, but some
>>> of the speakers were arguing against standardization. The basis of
>>> this argument was that the mobile industry only understands standards,
>>> but the satellite industry is currently differentiating based on
>>> custom systems and capabilities. The feeling was that the satellite
>>> industry had focused on technology and not regulations or standards
>>> and changing that course would not be helpful to the industry in the
>>> short term. Timing is important in this analysis because almost
>>> everyone agreed that at some point, standardization would be a good
>>> thing, but the concern was the best way to get to the point in the
>>> future. The other interesting argument against closer integration
>>> between wireless and satellite had to do with the business model.
>>> Several speakers questioned where the customers would go as
>>> terrestrial and non-terrestrial networks become more integrated. The
>>> underlying issues seemed to include who is responsible for solving
>>> network issues and perhaps more importantly, who recognizes the
>>> revenue. These issues seem, perhaps a bit simplistically, to be
>>> similar to early wireless roaming issues. While these issues created
>>> turbulence in the wireless market, they were solved and that is
>>> probably a template to address these challenges for the wireless and
>>> satellite operators."/
>>> /
>>> /
>>> Comments?
>>
>>
>> It is an interesting report.
>>
>> For standardisation standpoint, it seems SDOs do push towards
>> integration of 5G/6G and satcom; there are strong initiatives at least
>> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
>> these are SDOs traditionally oriented to land communications, rather
>> than space satcom.
>>
>> I wonder whether space satcom traditional SDOs (which ones?) have
>> initiated work towards integration with 5G/6G and other land-based
>> Internet?
>>
>> Alex
>>
>>>
>>> Hesham
>>>
>>> _______________________________________________
>>> 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
>>
>

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

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

[Alexandre Petrescu]

Le 30/08/2023 à 18:51, Inemesit Affia a écrit :
> With the existence of solutions like OpenMTCProuter, SDWAN, policy 
> based routing or any solution in general that allows combination in a 
> sense of any number of IP links, I really don't see a point for 
> specific solutions. Can anyone enlighten me?

I would be interested to see how MTCP, QUIC, SDWAN and policy based 
routing can help an end-user smartphone take advantage simultaneously of 
a low latency offered by a drone-airplane and of a high bandwidth 
offered by a MEO-GEO sat.  This would be an ideal solution for UE; it 
would compete directly with the latency and bandwidths offered by most 
advanced fiber or 6G ground links, but less cable kludge or antenna towers.

I think even Starlink goes somehow in that direction when it puts sats 
at 70km high altitudes: it lowers the altitude and thus reduces latency, 
even though not as low as what a drone/airplane can do at 500m high; 
that lower altitude is combined with their high bandwidth, but in a same 
sat.  And, not sure what kind of protocols Starlink uses (not known 
whether starlink sats have IP addresses,  neither whether they are IPv6 
addresses; not known about what kind of MPTCP or QUIC is there, or is it 
only a complete L2 network).

It is said somewhere that kepler (a competitor somehow to starlink) sats 
might carry BGP routers, so that would make kepler sats to have IP 
addresses inside, if so.  But even that is not sure: it is not really 
sure that kepler runs BGP on sat, or alternatively kepler sats is also 
an entire L2 network that transports BGP (and thus IP) packets through.


> For home users an issue may be IP blocks for certain services like 
> Netflix when the egress is out of a VPN or cloud provider richer than 
> a residential provider


Not sure what it means?

Alex


>
> On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink 
> <starlink@lists.bufferbloat.net> wrote:
>
>
>     Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>     > Here is a report which summarizes the outcome of the last
>     Satellites
>     > conference
>     >
>     [https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up]
>     >
>     > The report highlights the two main hurdles against the
>     integration of
>     > satellites and terrestrial networks: standardization and
>     business model.
>     >
>     > "/Most of the pushback against closer integration of terrestrial
>     > wireless and satellite networks revolved around standardization.
>     This
>     > may just be growing pains and it likely reflects the relative
>     > positions of wireless and satellite along the maturity curve,
>     but some
>     > of the speakers were arguing against standardization. The basis of
>     > this argument was that the mobile industry only understands
>     standards,
>     > but the satellite industry is currently differentiating based on
>     > custom systems and capabilities. The feeling was that the satellite
>     > industry had focused on technology and not regulations or standards
>     > and changing that course would not be helpful to the industry in
>     the
>     > short term. Timing is important in this analysis because almost
>     > everyone agreed that at some point, standardization would be a good
>     > thing, but the concern was the best way to get to the point in the
>     > future. The other interesting argument against closer integration
>     > between wireless and satellite had to do with the business model.
>     > Several speakers questioned where the customers would go as
>     > terrestrial and non-terrestrial networks become more integrated.
>     The
>     > underlying issues seemed to include who is responsible for solving
>     > network issues and perhaps more importantly, who recognizes the
>     > revenue. These issues seem, perhaps a bit simplistically, to be
>     > similar to early wireless roaming issues. While these issues
>     created
>     > turbulence in the wireless market, they were solved and that is
>     > probably a template to address these challenges for the wireless
>     and
>     > satellite operators."/
>     > /
>     > /
>     > Comments?
>
>
>     It is an interesting report.
>
>     For standardisation standpoint, it seems SDOs do push towards
>     integration of 5G/6G and satcom; there are strong initiatives at
>     least
>     at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
>     these are SDOs traditionally oriented to land communications, rather
>     than space satcom.
>
>     I wonder whether space satcom traditional SDOs (which ones?) have
>     initiated work towards integration with 5G/6G and other land-based
>     Internet?
>
>     Alex
>
>     >
>     > Hesham
>     >
>     > _______________________________________________
>     > 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
>

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

[David Lang]

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

On Thu, 31 Aug 2023, Alexandre Petrescu via Starlink wrote:

>> With the existence of solutions like OpenMTCProuter, SDWAN, policy 
>> based routing or any solution in general that allows combination in a 
>> sense of any number of IP links, I really don't see a point for 
>> specific solutions. Can anyone enlighten me?
>
> I would be interested to see how MTCP, QUIC, SDWAN and policy based 
> routing can help an end-user smartphone take advantage simultaneously of 
> a low latency offered by a drone-airplane and of a high bandwidth 
> offered by a MEO-GEO sat.  This would be an ideal solution for UE; it 
> would compete directly with the latency and bandwidths offered by most 
> advanced fiber or 6G ground links, but less cable kludge or antenna towers.

This isn't done on the phone, it's done on your wifi router.

the phone-to-satellite systems are very low bandwidth, and are probably always 
going to be due to the large footprint of each satellite (each 'cell' is very 
large, and you can only have one tansmitter on a given frequency in a given 
'cell'. It's good for low-bandwidth needs as a result

Cell service in urban areas gets it's high bandwidth by having lots of tiny 
cells (5g gets them down to a block or so) so that a given frequency can be 
re-used in a shorter distance.

When I do wifi for the Scale conference (3k+ geeks showing up to the Pasadena 
Convention Center), I run over 100 APs on low power at ground level for the same 
reason.

Even massive satellite antennas (IIRC 25 meter dishes) cannot focus the signal 
down to a area less than 10s of miles wide from orbit, and such large antennas 
cause significant drag at lower altitudes.


once you are taking IP locally from the dish, it's just another ISP (and like 
many residential ISPs, it has limits on incoming traffic). The biggest problem 
is that since the data rate changes frequently, existing rate adaptation 
struggles. It would be really nice to be able to query the dish (or better yet 
subscribe to a feed) to get expected bandwidth as it changes

David Lang


> I think even Starlink goes somehow in that direction when it puts sats 
> at 70km high altitudes: it lowers the altitude and thus reduces latency, 
> even though not as low as what a drone/airplane can do at 500m high; 
> that lower altitude is combined with their high bandwidth, but in a same 
> sat.  And, not sure what kind of protocols Starlink uses (not known 
> whether starlink sats have IP addresses,  neither whether they are IPv6 
> addresses; not known about what kind of MPTCP or QUIC is there, or is it 
> only a complete L2 network).
>
> It is said somewhere that kepler (a competitor somehow to starlink) sats 
> might carry BGP routers, so that would make kepler sats to have IP 
> addresses inside, if so.  But even that is not sure: it is not really 
> sure that kepler runs BGP on sat, or alternatively kepler sats is also 
> an entire L2 network that transports BGP (and thus IP) packets through.
>
>
>> For home users an issue may be IP blocks for certain services like 
>> Netflix when the egress is out of a VPN or cloud provider richer than 
>> a residential provider
>
>
> Not sure what it means?
>
> Alex
>
>
>>
>> On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink 
>> <starlink@lists.bufferbloat.net> wrote:
>>
>>
>>     Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>>     > Here is a report which summarizes the outcome of the last
>>     Satellites
>>     > conference
>>     >
>> 
> [https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up]
>>     >
>>     > The report highlights the two main hurdles against the
>>     integration of
>>     > satellites and terrestrial networks: standardization and
>>     business model.
>>     >
>>     > "/Most of the pushback against closer integration of terrestrial
>>     > wireless and satellite networks revolved around standardization.
>>     This
>>     > may just be growing pains and it likely reflects the relative
>>     > positions of wireless and satellite along the maturity curve,
>>     but some
>>     > of the speakers were arguing against standardization. The basis of
>>     > this argument was that the mobile industry only understands
>>     standards,
>>     > but the satellite industry is currently differentiating based on
>>     > custom systems and capabilities. The feeling was that the satellite
>>     > industry had focused on technology and not regulations or standards
>>     > and changing that course would not be helpful to the industry in
>>     the
>>     > short term. Timing is important in this analysis because almost
>>     > everyone agreed that at some point, standardization would be a good
>>     > thing, but the concern was the best way to get to the point in the
>>     > future. The other interesting argument against closer integration
>>     > between wireless and satellite had to do with the business model.
>>     > Several speakers questioned where the customers would go as
>>     > terrestrial and non-terrestrial networks become more integrated.
>>     The
>>     > underlying issues seemed to include who is responsible for solving
>>     > network issues and perhaps more importantly, who recognizes the
>>     > revenue. These issues seem, perhaps a bit simplistically, to be
>>     > similar to early wireless roaming issues. While these issues
>>     created
>>     > turbulence in the wireless market, they were solved and that is
>>     > probably a template to address these challenges for the wireless
>>     and
>>     > satellite operators."/
>>     > /
>>     > /
>>     > Comments?
>>
>>
>>     It is an interesting report.
>>
>>     For standardisation standpoint, it seems SDOs do push towards
>>     integration of 5G/6G and satcom; there are strong initiatives at
>>     least
>>     at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
>>     these are SDOs traditionally oriented to land communications, rather
>>     than space satcom.
>>
>>     I wonder whether space satcom traditional SDOs (which ones?) have
>>     initiated work towards integration with 5G/6G and other land-based
>>     Internet?
>>
>>     Alex
>>
>>     >
>>     > Hesham
>>     >
>>     > _______________________________________________
>>     > 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
>

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

[Inemesit Affia]

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

For the US military, starlink has already allowed two antenna/terminal
manufacturers to connect to the network.

Ball aerospace for aircraft.

DUJUD(hope I got that right) for regular user terminals.

Any antenna that connects with OneWeb should theoretically work apart from
the DRM

On Wed, Aug 30, 2023, 8:36 PM David Lang <david@lang.hm> wrote:

> Exactly my thoughts (I haven't downloaded and read the full report yet).
> What
> are they looking to do with this 'integration'? I can integrate my
> starlink just
> like any other ISP.
>
> or are they looking at the 'cell phones to orbit' functionality thats due
> to
> roll out very suddently
>
> or are they looking for "intergration" as another way to say "force SpaceX
> to
> open the specs for Starlink and allow other user terminals to interact
> with the
> Starlink satellites?
>
> The cynic in me says it's the latter.
>
> long term it may make sense to do this to some degree, but we are WAY too
> early
> to define "Interoperability Standards" and block people from coming up
> with
> better ways to do things.
>
> the Apple vs SpaceX cellphone-to-satellite have completely different ways
> of
> operating, and who wants to tell all the Apple people that their way isn't
> going
> to be the standard (or worse, that it is and they have to give everyone
> else the
> ability to use their currently proprietary protocol)
>
> David Lang
>
> On Wed, 30 Aug 2023, Inemesit Affia via Starlink wrote:
>
> > With the existence of solutions like OpenMTCProuter, SDWAN, policy based
> > routing or any solution in general that allows combination in a sense of
> > any number of IP links, I really don't see a point for specific
> solutions.
> > Can anyone enlighten me?
> >
> > For home users an issue may be IP blocks for certain services like
> Netflix
> > when the egress is out of a VPN or cloud provider richer than a
> residential
> > provider
> >
> > On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
> > starlink@lists.bufferbloat.net> wrote:
> >
> >>
> >> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
> >>> Here is a report which summarizes the outcome of the last Satellites
> >>> conference
> >>> [
> >>
> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
> >> ]
> >>>
> >>> The report highlights the two main hurdles against the integration of
> >>> satellites and terrestrial networks: standardization and business
> model.
> >>>
> >>> "/Most of the pushback against closer integration of terrestrial
> >>> wireless and satellite networks revolved around standardization. This
> >>> may just be growing pains and it likely reflects the relative
> >>> positions of wireless and satellite along the maturity curve, but some
> >>> of the speakers were arguing against standardization. The basis of
> >>> this argument was that the mobile industry only understands standards,
> >>> but the satellite industry is currently differentiating based on
> >>> custom systems and capabilities. The feeling was that the satellite
> >>> industry had focused on technology and not regulations or standards
> >>> and changing that course would not be helpful to the industry in the
> >>> short term. Timing is important in this analysis because almost
> >>> everyone agreed that at some point, standardization would be a good
> >>> thing, but the concern was the best way to get to the point in the
> >>> future. The other interesting argument against closer integration
> >>> between wireless and satellite had to do with the business model.
> >>> Several speakers questioned where the customers would go as
> >>> terrestrial and non-terrestrial networks become more integrated. The
> >>> underlying issues seemed to include who is responsible for solving
> >>> network issues and perhaps more importantly, who recognizes the
> >>> revenue. These issues seem, perhaps a bit simplistically, to be
> >>> similar to early wireless roaming issues. While these issues created
> >>> turbulence in the wireless market, they were solved and that is
> >>> probably a template to address these challenges for the wireless and
> >>> satellite operators."/
> >>> /
> >>> /
> >>> Comments?
> >>
> >>
> >> It is an interesting report.
> >>
> >> For standardisation standpoint, it seems SDOs do push towards
> >> integration of 5G/6G and satcom; there are strong initiatives at least
> >> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
> >> these are SDOs traditionally oriented to land communications, rather
> >> than space satcom.
> >>
> >> I wonder whether space satcom traditional SDOs (which ones?) have
> >> initiated work towards integration with 5G/6G and other land-based
> >> Internet?
> >>
> >> Alex
> >>
> >>>
> >>> Hesham
> >>>
> >>> _______________________________________________
> >>> 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
>

[-- Attachment #2: Type: text/html, Size: 7407 bytes --]

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

[Alexandre Petrescu]

Le 01/09/2023 à 18:27, Inemesit Affia a écrit :
> For the US military, starlink has already allowed two
> antenna/terminal manufacturers to connect to the network.
> 
> Ball aerospace for aircraft.
> 
> DUJUD(hope I got that right) for regular user terminals.

Thanks, I did not know that.

It is not clear from the announcements I read whether Ball aerospace and
DUJUD are simply antennas (albeit complex) plugged into starlink boxes
with a 50 ohm RF cable, or are they more computing than that.

I must say that I dont know whether the original 'DISHY' is simply a
dish antenna with an analog amplifier and maybe some mechanical motor
steering, or whether DISHY includes a computer to execute some protocol,
some algorithm.

If DUJUD and Ball aerospace make more than just the antennas, maybe
program some computers, then indeed there can be a sharing of protocol
documents from SpaceX (starlink) to DUJUD and Ball aerospace.  At that
point we'd be talking maybe of licensing.  These might be the premisses
of a need of interoperability.

Alex

> 
> Any antenna that connects with OneWeb should theoretically work apart
>  from the DRM
> 
> On Wed, Aug 30, 2023, 8:36 PM David Lang <david@lang.hm 
> <mailto:david@lang.hm>> wrote:
> 
> Exactly my thoughts (I haven't downloaded and read the full report 
> yet). What are they looking to do with this 'integration'? I can
> integrate my starlink just like any other ISP.
> 
> or are they looking at the 'cell phones to orbit' functionality thats
> due to roll out very suddently
> 
> or are they looking for "intergration" as another way to say "force 
> SpaceX to open the specs for Starlink and allow other user terminals
> to interact with the Starlink satellites?
> 
> The cynic in me says it's the latter.
> 
> long term it may make sense to do this to some degree, but we are WAY
> too early to define "Interoperability Standards" and block people
> from coming up with better ways to do things.
> 
> the Apple vs SpaceX cellphone-to-satellite have completely different 
> ways of operating, and who wants to tell all the Apple people that
> their way isn't going to be the standard (or worse, that it is and
> they have to give everyone else the ability to use their currently
> proprietary protocol)
> 
> David Lang
> 
> On Wed, 30 Aug 2023, Inemesit Affia via Starlink wrote:
> 
>> With the existence of solutions like OpenMTCProuter, SDWAN,
> policy based
>> routing or any solution in general that allows combination in a
> sense of
>> any number of IP links, I really don't see a point for specific
> solutions.
>> Can anyone enlighten me?
>> 
>> For home users an issue may be IP blocks for certain services
> like Netflix
>> when the egress is out of a VPN or cloud provider richer than a
> residential
>> provider
>> 
>> On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink < 
>> starlink@lists.bufferbloat.net
> <mailto:starlink@lists.bufferbloat.net>> wrote:
>> 
>>> 
>>> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>>>> Here is a report which summarizes the outcome of the last
> Satellites
>>>> conference [
>>> 
> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
> <https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up>
>
> 
>> ]
>>>> 
>>>> The report highlights the two main hurdles against the
> integration of
>>>> satellites and terrestrial networks: standardization and
> business model.
>>>> 
>>>> "/Most of the pushback against closer integration of
>>>> terrestrial wireless and satellite networks revolved around
> standardization. This
>>>> may just be growing pains and it likely reflects the relative 
>>>> positions of wireless and satellite along the maturity curve,
> but some
>>>> of the speakers were arguing against standardization. The basis
>>>> of this argument was that the mobile industry only understands
> standards,
>>>> but the satellite industry is currently differentiating based
>>>> on custom systems and capabilities. The feeling was that the
>>>> satellite industry had focused on technology and not
>>>> regulations or standards and changing that course would not be
>>>> helpful to the industry
> in the
>>>> short term. Timing is important in this analysis because
>>>> almost everyone agreed that at some point, standardization
>>>> would be a good thing, but the concern was the best way to get
>>>> to the point in the future. The other interesting argument
>>>> against closer integration between wireless and satellite had
>>>> to do with the business model. Several speakers questioned
>>>> where the customers would go as terrestrial and non-terrestrial
>>>> networks become more
> integrated. The
>>>> underlying issues seemed to include who is responsible for
>>>> solving network issues and perhaps more importantly, who
>>>> recognizes the revenue. These issues seem, perhaps a bit
>>>> simplistically, to be similar to early wireless roaming issues.
>>>> While these issues
> created
>>>> turbulence in the wireless market, they were solved and that
>>>> is probably a template to address these challenges for the
> wireless and
>>>> satellite operators."/ / / Comments?
>>> 
>>> 
>>> It is an interesting report.
>>> 
>>> For standardisation standpoint, it seems SDOs do push towards 
>>> integration of 5G/6G and satcom; there are strong initiatives at
> least
>>> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.
>>> But these are SDOs traditionally oriented to land communications,
>>> rather than space satcom.
>>> 
>>> I wonder whether space satcom traditional SDOs (which ones?)
>>> have initiated work towards integration with 5G/6G and other
>>> land-based Internet?
>>> 
>>> Alex
>>> 
>>>> 
>>>> Hesham
>>>> 
>>>> _______________________________________________ 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
> <mailto:Starlink@lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink
> <https://lists.bufferbloat.net/listinfo/starlink>
>>> 
>> _______________________________________________
> Starlink mailing list Starlink@lists.bufferbloat.net
> <mailto:Starlink@lists.bufferbloat.net> 
> https://lists.bufferbloat.net/listinfo/starlink 
> <https://lists.bufferbloat.net/listinfo/starlink>
> 

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

[Ulrich Speidel]

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


On 15/09/2023 11:29 pm, Alexandre Petrescu via Starlink wrote:
>
> I must say that I dont know whether the original 'DISHY' is simply a
> dish antenna with an analog amplifier and maybe some mechanical motor
> steering, or whether DISHY includes a computer to execute some protocol,
> some algorithm.

It's a phased array, not a dish, even if it looks like one. It consists 
of 100's of fingernail-sized antenna elements that:

  * during transmissions, have an individual phase delay added to the
    signal transmitted from that element, in order to permit
    transmission of the combined signal from all elements into a
    particular direction.
  * during reception, have an individual phase delay added to the signal
    collected by that element, before the signals are added to obtain
    the combined received signal. This allows reception from a
    particular direction.

Dishy's main direction of transmission / reception is therefore not its 
surface normal - this simply points to the area of the sky where Dishy 
expects to see most satellites (a function of geographical latitude and 
constellation design - essentially straight up in the tropics, and 
elsewhere in the direction of the 53rd parallel, which corresponds to 
the predominant orbital inclination in the Starlink fleet). The actual 
tracking is then done with the phased array without mechanical movement 
by Dishy.

 From what I've seen, Dishy seems to consume more power on receive than 
on transmit - that's if you actually download stuff. This is somewhat 
counter-intuitive if you're used to putting link budgets together. But 
I'd attribute that to a higher degree of digital signal processing 
required on the receive and demodulation path.

-- 

****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 2845 bytes --]

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

[David Lang]

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

On Sat, 16 Sep 2023, Ulrich Speidel via Starlink wrote:

> On 15/09/2023 11:29 pm, Alexandre Petrescu via Starlink wrote:
>> 
>> I must say that I dont know whether the original 'DISHY' is simply a
>> dish antenna with an analog amplifier and maybe some mechanical motor
>> steering, or whether DISHY includes a computer to execute some protocol,
>> some algorithm.

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.

There are numberous teardown videos on youtube now, for both the original and 
the 1st of the rectangular dishys, they will show you how complex the system is.

David Lang

  >
> It's a phased array, not a dish, even if it looks like one. It consists of 
> 100's of fingernail-sized antenna elements that:
>
> * during transmissions, have an individual phase delay added to the
>   signal transmitted from that element, in order to permit
>   transmission of the combined signal from all elements into a
>   particular direction.
> * during reception, have an individual phase delay added to the signal
>   collected by that element, before the signals are added to obtain
>   the combined received signal. This allows reception from a
>   particular direction.
>
> Dishy's main direction of transmission / reception is therefore not its 
> surface normal - this simply points to the area of the sky where Dishy 
> expects to see most satellites (a function of geographical latitude and 
> constellation design - essentially straight up in the tropics, and elsewhere 
> in the direction of the 53rd parallel, which corresponds to the predominant 
> orbital inclination in the Starlink fleet). The actual tracking is then done 
> with the phased array without mechanical movement by Dishy.
>
> From what I've seen, Dishy seems to consume more power on receive than on 
> transmit - that's if you actually download stuff. This is somewhat 
> counter-intuitive if you're used to putting link budgets together. But I'd 
> attribute that to a higher degree of digital signal processing required on 
> the receive and demodulation path.
>
>

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

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

[Ulrich Speidel]

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.

-- 

****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************

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

[Alexandre Petrescu]

Le 15/09/2023 à 17:18, Ulrich Speidel via Starlink a écrit :
>
>
> On 15/09/2023 11:29 pm, Alexandre Petrescu via Starlink wrote:
>>
>> I must say that I dont know whether the original 'DISHY' is simply a
>> dish antenna with an analog amplifier and maybe some mechanical motor
>> steering, or whether DISHY includes a computer to execute some protocol,
>> some algorithm.
>
> It's a phased array, not a dish, even if it looks like one. It 
> consists of 100's of fingernail-sized antenna elements that:
>
>   * during transmissions, have an individual phase delay added to the
>     signal transmitted from that element, in order to permit
>     transmission of the combined signal from all elements into a
>     particular direction.
>   * during reception, have an individual phase delay added to the
>     signal collected by that element, before the signals are added to
>     obtain the combined received signal. This allows reception from a
>     particular direction.
>
> Dishy's main direction of transmission / reception is therefore not 
> its surface normal - this simply points to the area of the sky where 
> Dishy expects to see most satellites (a function of geographical 
> latitude and constellation design - essentially straight up in the 
> tropics, and elsewhere in the direction of the 53rd parallel, which 
> corresponds to the predominant orbital inclination in the Starlink 
> fleet). The actual tracking is then done with the phased array without 
> mechanical movement by Dishy.
>
Thanks for the description.  It is an advanced and interesting antenna 
behaviour for a consumer product.  It is good the mechanical motor is 
replaced with phasing.

More advanced phasing is probably used in their antenna version for 
automobiles, but might be the same principles.

Then, for ships, where more 3D-imensional like movements exist, 
replacing big motors with phasing can represent significant gains in 
terms of space occupied.

> From what I've seen, Dishy seems to consume more power on receive than 
> on transmit - that's if you actually download stuff. This is somewhat 
> counter-intuitive if you're used to putting link budgets together. But 
> I'd attribute that to a higher degree of digital signal processing 
> required on the receive and demodulation path.
>
It is interesting it consumes more on receive than on transmit. Thanks.

There was a pointer here pointing to an ETSI document about what might 
be a sort of certification (access to medium to not disturb the 
others).  In it, it seems a different freq is used for transmit than for 
receive. (12 vs 14GHz, or so, or vice-versa). The difference in frquency 
might also be a factor (in addition to the dsp calculus you mention) in 
differentiating the consumption up vs download.  I'd expect working with 
higher freuencies to require more energy.  But I am not sure an ETSI 
document can be for US starlink end user device.

Alex

> -- 
> ****************************************************************
> Dr. Ulrich Speidel
>
> School of Computer Science
>
> Room 303S.594 (City Campus)
>
> The University of Auckland
> u.speidel@auckland.ac.nz  
> http://www.cs.auckland.ac.nz/~ulrich/
> ****************************************************************
>
>
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

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

[Alexandre Petrescu]

Le 15/09/2023 à 19:52, David Lang via Starlink a écrit :
> On Sat, 16 Sep 2023, Ulrich Speidel via Starlink wrote:
>
>> On 15/09/2023 11:29 pm, Alexandre Petrescu via Starlink wrote:
>>>
>>> I must say that I dont know whether the original 'DISHY' is simply a
>>> dish antenna with an analog amplifier and maybe some mechanical motor
>>> steering, or whether DISHY includes a computer to execute some 
>>> protocol,
>>> some algorithm.
>
> 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.
>
> There are numberous teardown videos on youtube now, for both the 
> original and the 1st of the rectangular dishys, they will show you how 
> complex the system is.

Thanks for the note.  It's always interesting to look at teardowns.

The Ethernet/IP capability in the antenna box is very promising.

If I had one, the first think I'd do is to use wireshark to listen on 
that Ethernet port to see whether it sends Router Advertisements (IPv6).

People say IPv6 is supported but there are many ways in which IPv6 can 
be 'supported', and some are better than others, not the least being 
NAT66, IPv6-in-IPv4 and the prefix length (64 or not).  And DHCPv6 of 
course.  Native vs non native IPv6, in short.

Alex

>
> David Lang
>
>  >
>> It's a phased array, not a dish, even if it looks like one. It 
>> consists of 100's of fingernail-sized antenna elements that:
>>
>> * during transmissions, have an individual phase delay added to the
>>   signal transmitted from that element, in order to permit
>>   transmission of the combined signal from all elements into a
>>   particular direction.
>> * during reception, have an individual phase delay added to the signal
>>   collected by that element, before the signals are added to obtain
>>   the combined received signal. This allows reception from a
>>   particular direction.
>>
>> Dishy's main direction of transmission / reception is therefore not 
>> its surface normal - this simply points to the area of the sky where 
>> Dishy expects to see most satellites (a function of geographical 
>> latitude and constellation design - essentially straight up in the 
>> tropics, and elsewhere in the direction of the 53rd parallel, which 
>> corresponds to the predominant orbital inclination in the Starlink 
>> fleet). The actual tracking is then done with the phased array 
>> without mechanical movement by Dishy.
>>
>> From what I've seen, Dishy seems to consume more power on receive 
>> than on transmit - that's if you actually download stuff. This is 
>> somewhat counter-intuitive if you're used to putting link budgets 
>> together. But I'd attribute that to a higher degree of digital signal 
>> processing required on the receive and demodulation path.
>>
>>
>
> _______________________________________________
> 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

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

[Alexandre Petrescu]

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

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

[Steve Stroh]

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

Correction - Dishy has a motor AND a phased array antenna.

Dishy figures out the best direction and azimuth to orient the antenna and
uses the motor to do so. The phased array then tracks the orbital
progression of each satellite it chooses to use for maximum SNR.

I’ve read that the motor can also be used in creative ways like tipping
itself to as close to vertical as possible to remove accumulated snow.

You can choose to lock (disable) the motor - I’ve seen this done for fixed
installations like RVs and boats and if there are no obstacles such as
trees and there’s a sufficient density of sats in your location, “motor
off” mode can work reasonably well.

Steve Stroh

On Sun, Sep 17, 2023 at 10:09 Alexandre Petrescu via Starlink <
starlink@lists.bufferbloat.net> wrote:

>
> Thanks for the description.  It is an advanced and interesting antenna
> behaviour for a consumer product.  It is good the mechanical motor is
> replaced with phasing.
>
> More advanced phasing is probably used in their antenna version for
> automobiles, but might be the same principles.
>
> Then, for ships, where more 3D-imensional like movements exist,
> replacing big motors with phasing can represent significant gains in
> terms of space occupied.
>
> It is interesting it consumes more on receive than on transmit. Thanks.
>
> There was a pointer here pointing to an ETSI document about what might
> be a sort of certification (access to medium to not disturb the
> others).  In it, it seems a different freq is used for transmit than for
> receive. (12 vs 14GHz, or so, or vice-versa). The difference in frquency
> might also be a factor (in addition to the dsp calculus you mention) in
> differentiating the consumption up vs download.  I'd expect working with
> higher freuencies to require more energy.  But I am not sure an ETSI
> document can be for US starlink end user device.
>
> Alex
>
> > --
> > ****************************************************************
> > Dr. Ulrich Speidel
> >
> > School of Computer Science
> >
> > Room 303S.594 (City Campus)
> >
> > The University of Auckland
> > u.speidel@auckland.ac.nz
> > http://www.cs.auckland.ac.nz/~ulrich/
> > ****************************************************************
>
>

[-- Attachment #2: Type: text/html, Size: 3117 bytes --]

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

[David Lang]

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

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>
> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> 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
>

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

[Hesham ElBakoury]

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

Given the discussions in this email thread, what IETF should standardize in
priority order  for the integrated NTN terrestrial networks?

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 <starlink@lists.bufferbloat.net>
> > Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> > 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
>

[-- Attachment #2: Type: text/html, Size: 4632 bytes --]

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

[David Lang]

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

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 <starlink@lists.bufferbloat.net>
>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>> 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
>>
>

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

[Hesham ElBakoury]

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

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 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 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 <starlink@lists.bufferbloat.net>
> >>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> >>> 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
> >>
> >

[-- Attachment #2: Type: text/html, Size: 6797 bytes --]

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

[David Lang]

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

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 <david@lang.hm> 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 <starlink@lists.bufferbloat.net>
>>>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>>>> 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
>>>>
>>>
>

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

[Jorge Amodio]

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

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 PM 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
> 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 <david@lang.hm> 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 <
> starlink@lists.bufferbloat.net>
> >>>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> >>>>> 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
>

[-- Attachment #2: Type: text/html, Size: 9636 bytes --]

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

[David Lang]

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

Very much so. If we are talking about integrating Starlink (and similar furture 
networks) with ground based networks, that's not hard (and is the scenario I was 
referring to)

but when we start talking about mars (and possibly even the moon) the existing 
networking protocols are going to time out. I expect that for a long time it's 
going to be some sort of batch protocol, possibly pulling UUCP back out and 
using it (with some forward error correction at the link layer) rather than the 
interactive protocols that we see in use today.

David Lang

On Mon, 18 Sep 2023, Jorge Amodio wrote:

> 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 PM 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
>> 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 <david@lang.hm> 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 <
>> starlink@lists.bufferbloat.net>
>>>>>>> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
>>>>>>> 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
>>
>

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

[Alexandre Petrescu]

Le 19/09/2023 à 01:32, Hesham ElBakoury a écrit :
> Given the discussions in this email thread, what IETF should standardize 
> in priority order  for the integrated NTN terrestrial networks?

Maybe make the NTN networks run IP, and preferably IPv6.  It would be a 
good step towards integrating with the IP flat networks on the ground.

(yes, I know, many will say that starlink does support IP and even IPv6, 
but I believe there is no IP in the sats; or maybe I have to read more).

Alex

> 
> 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 <mailto:Starlink@lists.bufferbloat.net>
>     https://lists.bufferbloat.net/listinfo/starlink
>     <https://lists.bufferbloat.net/listinfo/starlink>
> 

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

[Alexandre Petrescu]

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.

IF on the other hand, starlink feels a need to interoperate, then we can
discuss.

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.

> 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).

Then, when they'll want to remove that they'd hit into the /64 issue.

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
> <mailto:Starlink@lists.bufferbloat.net>
>>> https://lists.bufferbloat.net/listinfo/starlink
> <https://lists.bufferbloat.net/listinfo/starlink>
>>> 
>> 
> 

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

[David Lang]

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

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
>> <mailto:Starlink@lists.bufferbloat.net>
>>>> https://lists.bufferbloat.net/listinfo/starlink
>> <https://lists.bufferbloat.net/listinfo/starlink>
>>>> 
>>> 
>> 
>

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

[David Lang]

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

On Tue, 19 Sep 2023, Alexandre Petrescu wrote:

> Le 19/09/2023 à 01:32, Hesham ElBakoury a écrit :
>> Given the discussions in this email thread, what IETF should standardize in 
>> priority order  for the integrated NTN terrestrial networks?
>
> Maybe make the NTN networks run IP, and preferably IPv6.  It would be a good 
> step towards integrating with the IP flat networks on the ground.

if you want Starlink to run IPv6, then I think that someone needs to show how it 
would work in such a dynamic environment, with the links/paths changing every 
few minutes, and the ground stations moving as well. I've seen papers on mobile 
IP addresses in the past, but those have all involved so much tunneling that it 
really hasn't mattered if the underlying network is IP or not,

> (yes, I know, many will say that starlink does support IP and even IPv6, but 
> I believe there is no IP in the sats; or maybe I have to read more).

I don't think anyone knows what the in-space protocols are. We know there is not 
in-space routing, so it's no longer a matter of simple bent-pipe relaying, but I 
haven't heard of any leaks/papers on the topic (if there are any, I'm 
interested, but haven't gone digging, counting on others to find them and bring 
it up here :-) )

David Lang

> Alex
>
>> 
>> 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 <mailto:Starlink@lists.bufferbloat.net>
>>     https://lists.bufferbloat.net/listinfo/starlink
>>     <https://lists.bufferbloat.net/listinfo/starlink>
>> 
>

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

[emile.stephan]

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

+1, in fine these ones are a bit more terrestrial

De : Sat-int <sat-int-bounces@ietf.org> De la part de Jorge Amodio
Envoyé : mardi 19 septembre 2023 03:08
À : David Lang <david@lang.hm>
Cc : Hesham ElBakoury <helbakoury@gmail.com>; Alexandre Petrescu <alexandre.petrescu@gmail.com>; Dave Taht via Starlink <starlink@lists.bufferbloat.net>; sat-int@ietf.org
Objet : Re: [Sat-int] [Starlink] Main hurdles against the Integration of Satellites and Terrestial Networks


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 PM David Lang <david@lang.hm<mailto: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
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 <david@lang.hm<mailto:david@lang.hm>> 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<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
>>>>> _______________________________________________
>>>> Starlink mailing list
>>>> Starlink@lists.bufferbloat.net<mailto:Starlink@lists.bufferbloat.net>
>>>> https://lists.bufferbloat.net/listinfo/starlink
>>>>
>>>
>--
Sat-int mailing list
Sat-int@ietf.org<mailto:Sat-int@ietf.org>
https://www.ietf.org/mailman/listinfo/sat-int


Orange Restricted
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

[-- Attachment #2: Type: text/html, Size: 14183 bytes --]

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

[Alexandre Petrescu]

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 <david@lang.hm 
> <mailto: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 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 <david@lang.hm
> <mailto:david@lang.hm>> 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
> <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
> <mailto:Starlink@lists.bufferbloat.net>
>>>>> https://lists.bufferbloat.net/listinfo/starlink
> <https://lists.bufferbloat.net/listinfo/starlink>
>>>>> 
>>>> 
>> --
> Sat-int mailing list Sat-int@ietf.org <mailto:Sat-int@ietf.org> 
> https://www.ietf.org/mailman/listinfo/sat-int 
> <https://www.ietf.org/mailman/listinfo/sat-int>
> 

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

[Alexandre Petrescu]

Le 16/10/2023 à 15:26, David Fernández via Starlink a écrit :
> Regarding this: "The SDA standard (:
> https://www.sda.mil/wp-content/uploads/2022/04/SDA-OCT-Standard-v3.0.pdf)

This document looks like a standard of a communication system. For 
example it has a packet format (figure 11 "FSO Payload Frame Format").

One could think about further specifying how to transmit IP packets on it.


> requires beaconless PAT without a side channel to sync the two OCTs,
> which makes things much harder. Acquisition times are longer, and
> initial pointing requires extremely accurate knowledege of the
> position of the other side, which greatly increases cost."
>
> Following the example of the SDA (Space Development Agency), ESA has
> also now an optical link specification for 2.5 Gbps, 10 Gbps and 100 /
> 200 /400 Gbps per channel consolidated with the help of 18 European
> industries.
Has it?  Or is it in project phase?
>
> See the link to ESTOL (ESA Specification for Terabit/sec Optical
> Links) here: https://www.esa.int/Applications/Connectivity_and_Secure_Communications/European_space_firms_set_specifications_for_optical_links

At that URL there is a "ESA Specifications for Terabit/second Optical 
Links" https://esamultimedia.esa.int/docs/CSC/ESTOL.pdf

It refers some times to "Open ROADM", but not sure what is this "Open 
ROADM".  The URL http://www.openroadm.org/ is insecure.  Its https 
counterpart URL tells "SSL_ERROR_NO_CYPHER_OVERLAP".

The ESTOL and OCT frame formats seem to be different (Figure 4 "2.5G OOK 
frame structure" vs Figure 11 "FSO Payload Frame Format")


At the same time, there is now this Horizon Europe call for projects 
ongoing in the Space destination of Cluster 4 
"HORIZON-CL4-2024-SPACE-01-73".  Sorry for the acronym speech.

It calls for a few things, among which "High data rate (12.5 to 28 Gbps 
or higher 56 Gbps), low consumption, short range links [Target TRL 7]" 
among other things.

Maybe ESTOL is the same thing as it is called for by this call, or maybe 
ESTOL is for space-to-ground and this call is for ISL. It is not clear 
to me.

>
> The ESTOL follows the PAT process of SDA due to compatibility with
> existing European terminal suppliers.
>
> The ‘beaconless’ PAT is not necessarily performing worse than having a
> side channel; it simply means that the communications wavelength is
> used also for initial acquisition and then for tracking.
> This is also the approach in EDRS
> (https://connectivity.esa.int/european-data-relay-satellite-system-edrs-overview)
> and actually SDA has formalized the EDRS approach.
>
> The separate wavelength (or beacon) may provide some advantages in
> space to ground links rather than space-space ISLs.

You seem to be understanding the ESTOL specs. I dont.

I might dare saying the following: if one would like interop between 
ESTOL and SDA OCT, maybe one wants to make a gateway with an ESTOL and 
an SDA OCT interface on it.

And have IP running and on SDA OCT, and on ESTOL.

For that to work, one would need an IP-over-SDA-OCT spec, and an 
IP-over-ESTOL spec.  These could come in the form of Internet Drafts 
proposed at IETF.

It  might be also possible that ESTOL does not yet fully exist as a 
spec; as such it could  be further adapted to be more compatible with 
SDA OCT.  At that point, a single Internet Draft 
"IP-over-OCT-kind-of-ESTOL" would be sufficient to gain interop.

>
> Starlink optical ISL at 100G is most likely reusing the terrestrial
> fibre optics COTS transceivers in space, as planned to do by Hydron
> (https://connectivity.esa.int/developing-future-optical-highcapacity-satellite-networks-hydron-high-throughput-optical-network)
> and ESTOL.

For Hydron: I did not know it, thanks.

For Starlink optical ISL: I think it could be several other things, and 
not necessarily ESTOL or Hydron.

Also some ESA calls point to these other laser devices for satcom:

- "TOSIRIS - Direct-to-Earth Laser Communication Terminal" ==> CCSDS.  
(is ESTOL the same as CCSDS?)

- TESAT Pixl - maybe the same as TOSIRIS(?)

- "SmallCAT laser communication system" ==> maybe also uses CCSDS.

- "OPTEL-μ: Optical Terminal for Small Satellite LEO Applications" ==> 
uses  MCS (Modulation and Coding Scheme, but I dont know what is it).

These seem to be small and affordable devices.

All in all, to me, the question is that of interoperability, because 
there are so many link layers up there.

Maybe SDA OCT, ESTOL and CCSDS are all the same thing, or maybe not.

The great thing would be to run IP on them.

Alex



>
> Regards,
>
> David
>
>> Date: Sat, 2 Sep 2023 20:44:06 -0700
>> From: Mike Puchol <mike@starlink.sx>
>> To: starlink@lists.bufferbloat.net
>> Subject: Re: [Starlink] Main hurdles against the Integration of
>> 	Satellites and Terrestial Networks
>> Message-ID: <8070d746-1aa0-45a6-8b0f-9bc4f01d1c8d@Spark>
>> Content-Type: text/plain; charset="utf-8"
>>
>> The ETSI standard you reference is a generic framework for testing &
>> measuring earth stations connecting to NGSO systems, so they may be using
>> it, but it’s not mandatory. In any case, the standard doesn’t have any
>> effect on the RF characteristics, the interoperability, etc.
>>
>> Regarding ISL, I would doubt they use the SDA OCT standard, except maybe for
>> Starshield payloads. The SDA standard requires beaconless PAT without a side
>> channel to sync the two OCTs, which makes things much harder. Acquisition
>> times are longer, and initial pointing requires extremely accurate
>> knowledege of the position of the other side, which greatly increases cost.
>>
>> Best,
>>
>> Mike
>> On Sep 2, 2023 at 18:03 -0700, David Fernández via Starlink
>> <starlink@lists.bufferbloat.net>, wrote:
>>> It seems that Starlink follows this norm, although it does not reflect
>>> the entire Starlink system specification:
>>> https://www.etsi.org/deliver/etsi_en/303900_303999/303981/01.02.00_30/en_303981v010200v.pdf
>>>
>>> Then, for the ISL, I suppose they are following this:
>>> https://www.sda.mil/wp-content/uploads/2022/04/SDA-OCT-Standard-v3.0.pdf
>>>
>>>> Date: Fri, 1 Sep 2023 17:27:30 +0100
>>>> From: Inemesit Affia <inemesitaffia@gmail.com>
>>>> To: David Lang <david@lang.hm>
>>>> Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>,
>>>> starlink@lists.bufferbloat.net
>>>> Subject: Re: [Starlink] Main hurdles against the Integration of
>>>> Satellites and Terrestial Networks
>>>> Message-ID:
>>>> <CAJEhh70CMSk_WAmd9sgXfMDoWZhhz5uPAU=d5UG3rW5XFkw1KQ@mail.gmail.com>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>> For the US military, starlink has already allowed two antenna/terminal
>>>> manufacturers to connect to the network.
>>>>
>>>> Ball aerospace for aircraft.
>>>>
>>>> DUJUD(hope I got that right) for regular user terminals.
>>>>
>>>> Any antenna that connects with OneWeb should theoretically work apart
>>>> from
>>>> the DRM
>>>>
>>>> On Wed, Aug 30, 2023, 8:36 PM David Lang <david@lang.hm> wrote:
>>>>
>>>>> Exactly my thoughts (I haven't downloaded and read the full report
>>>>> yet).
>>>>> What
>>>>> are they looking to do with this 'integration'? I can integrate my
>>>>> starlink just
>>>>> like any other ISP.
>>>>>
>>>>> or are they looking at the 'cell phones to orbit' functionality thats
>>>>> due
>>>>> to
>>>>> roll out very suddently
>>>>>
>>>>> or are they looking for "intergration" as another way to say "force
>>>>> SpaceX
>>>>> to
>>>>> open the specs for Starlink and allow other user terminals to interact
>>>>> with the
>>>>> Starlink satellites?
>>>>>
>>>>> The cynic in me says it's the latter.
>>>>>
>>>>> long term it may make sense to do this to some degree, but we are WAY
>>>>> too
>>>>> early
>>>>> to define "Interoperability Standards" and block people from coming up
>>>>> with
>>>>> better ways to do things.
>>>>>
>>>>> the Apple vs SpaceX cellphone-to-satellite have completely different
>>>>> ways
>>>>> of
>>>>> operating, and who wants to tell all the Apple people that their way
>>>>> isn't
>>>>> going
>>>>> to be the standard (or worse, that it is and they have to give
>>>>> everyone
>>>>> else the
>>>>> ability to use their currently proprietary protocol)
>>>>>
>>>>> David Lang
>>>>>
>>>>> On Wed, 30 Aug 2023, Inemesit Affia via Starlink wrote:
>>>>>
>>>>>> With the existence of solutions like OpenMTCProuter, SDWAN, policy
>>>>>> based
>>>>>> routing or any solution in general that allows combination in a
>>>>>> sense of
>>>>>> any number of IP links, I really don't see a point for specific
>>>>> solutions.
>>>>>> Can anyone enlighten me?
>>>>>>
>>>>>> For home users an issue may be IP blocks for certain services like
>>>>> Netflix
>>>>>> when the egress is out of a VPN or cloud provider richer than a
>>>>> residential
>>>>>> provider
>>>>>>
>>>>>> On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
>>>>>> starlink@lists.bufferbloat.net> wrote:
>>>>>>
>>>>>>> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>>>>>>>> Here is a report which summarizes the outcome of the last
>>>>>>>> Satellites
>>>>>>>> conference
>>>>>>>> [
>>>>> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
>>>>>>> ]
>>>>>>>> The report highlights the two main hurdles against the
>>>>>>>> integration of
>>>>>>>> satellites and terrestrial networks: standardization and
>>>>>>>> business
>>>>> model.
>>>>>>>> "/Most of the pushback against closer integration of terrestrial
>>>>>>>> wireless and satellite networks revolved around standardization.
>>>>>>>> This
>>>>>>>> may just be growing pains and it likely reflects the relative
>>>>>>>> positions of wireless and satellite along the maturity curve,
>>>>>>>> but some
>>>>>>>> of the speakers were arguing against standardization. The basis
>>>>>>>> of
>>>>>>>> this argument was that the mobile industry only understands
>>>>>>>> standards,
>>>>>>>> but the satellite industry is currently differentiating based on
>>>>>>>> custom systems and capabilities. The feeling was that the
>>>>>>>> satellite
>>>>>>>> industry had focused on technology and not regulations or
>>>>>>>> standards
>>>>>>>> and changing that course would not be helpful to the industry in
>>>>>>>> the
>>>>>>>> short term. Timing is important in this analysis because almost
>>>>>>>> everyone agreed that at some point, standardization would be a
>>>>>>>> good
>>>>>>>> thing, but the concern was the best way to get to the point in
>>>>>>>> the
>>>>>>>> future. The other interesting argument against closer
>>>>>>>> integration
>>>>>>>> between wireless and satellite had to do with the business
>>>>>>>> model.
>>>>>>>> Several speakers questioned where the customers would go as
>>>>>>>> terrestrial and non-terrestrial networks become more integrated.
>>>>>>>> The
>>>>>>>> underlying issues seemed to include who is responsible for
>>>>>>>> solving
>>>>>>>> network issues and perhaps more importantly, who recognizes the
>>>>>>>> revenue. These issues seem, perhaps a bit simplistically, to be
>>>>>>>> similar to early wireless roaming issues. While these issues
>>>>>>>> created
>>>>>>>> turbulence in the wireless market, they were solved and that is
>>>>>>>> probably a template to address these challenges for the wireless
>>>>>>>> and
>>>>>>>> satellite operators."/
>>>>>>>> /
>>>>>>>> /
>>>>>>>> Comments?
>>>>>>>
>>>>>>> It is an interesting report.
>>>>>>>
>>>>>>> For standardisation standpoint, it seems SDOs do push towards
>>>>>>> integration of 5G/6G and satcom; there are strong initiatives at
>>>>>>> least
>>>>>>> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.
>>>>>>> But
>>>>>>> these are SDOs traditionally oriented to land communications,
>>>>>>> rather
>>>>>>> than space satcom.
>>>>>>>
>>>>>>> I wonder whether space satcom traditional SDOs (which ones?) have
>>>>>>> initiated work towards integration with 5G/6G and other land-based
>>>>>>> Internet?
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>> Hesham
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230902/9209f929/attachment-0001.html>
>>
>> ------------------------------
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

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

[David Fernández]

Regarding this: "The SDA standard (:
https://www.sda.mil/wp-content/uploads/2022/04/SDA-OCT-Standard-v3.0.pdf)
requires beaconless PAT without a side channel to sync the two OCTs,
which makes things much harder. Acquisition times are longer, and
initial pointing requires extremely accurate knowledege of the
position of the other side, which greatly increases cost."

Following the example of the SDA (Space Development Agency), ESA has
also now an optical link specification for 2.5 Gbps, 10 Gbps and 100 /
200 /400 Gbps per channel consolidated with the help of 18 European
industries.

See the link to ESTOL (ESA Specification for Terabit/sec Optical
Links) here: https://www.esa.int/Applications/Connectivity_and_Secure_Communications/European_space_firms_set_specifications_for_optical_links

The ESTOL follows the PAT process of SDA due to compatibility with
existing European terminal suppliers.

The ‘beaconless’ PAT is not necessarily performing worse than having a
side channel; it simply means that the communications wavelength is
used also for initial acquisition and then for tracking.
This is also the approach in EDRS
(https://connectivity.esa.int/european-data-relay-satellite-system-edrs-overview)
and actually SDA has formalized the EDRS approach.

The separate wavelength (or beacon) may provide some advantages in
space to ground links rather than space-space ISLs.

Starlink optical ISL at 100G is most likely reusing the terrestrial
fibre optics COTS transceivers in space, as planned to do by Hydron
(https://connectivity.esa.int/developing-future-optical-highcapacity-satellite-networks-hydron-high-throughput-optical-network)
and ESTOL.

Regards,

David

> Date: Sat, 2 Sep 2023 20:44:06 -0700
> From: Mike Puchol <mike@starlink.sx>
> To: starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Main hurdles against the Integration of
> 	Satellites and Terrestial Networks
> Message-ID: <8070d746-1aa0-45a6-8b0f-9bc4f01d1c8d@Spark>
> Content-Type: text/plain; charset="utf-8"
>
> The ETSI standard you reference is a generic framework for testing &
> measuring earth stations connecting to NGSO systems, so they may be using
> it, but it’s not mandatory. In any case, the standard doesn’t have any
> effect on the RF characteristics, the interoperability, etc.
>
> Regarding ISL, I would doubt they use the SDA OCT standard, except maybe for
> Starshield payloads. The SDA standard requires beaconless PAT without a side
> channel to sync the two OCTs, which makes things much harder. Acquisition
> times are longer, and initial pointing requires extremely accurate
> knowledege of the position of the other side, which greatly increases cost.
>
> Best,
>
> Mike
> On Sep 2, 2023 at 18:03 -0700, David Fernández via Starlink
> <starlink@lists.bufferbloat.net>, wrote:
>> It seems that Starlink follows this norm, although it does not reflect
>> the entire Starlink system specification:
>> https://www.etsi.org/deliver/etsi_en/303900_303999/303981/01.02.00_30/en_303981v010200v.pdf
>>
>> Then, for the ISL, I suppose they are following this:
>> https://www.sda.mil/wp-content/uploads/2022/04/SDA-OCT-Standard-v3.0.pdf
>>
>> > Date: Fri, 1 Sep 2023 17:27:30 +0100
>> > From: Inemesit Affia <inemesitaffia@gmail.com>
>> > To: David Lang <david@lang.hm>
>> > Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>,
>> > starlink@lists.bufferbloat.net
>> > Subject: Re: [Starlink] Main hurdles against the Integration of
>> > Satellites and Terrestial Networks
>> > Message-ID:
>> > <CAJEhh70CMSk_WAmd9sgXfMDoWZhhz5uPAU=d5UG3rW5XFkw1KQ@mail.gmail.com>
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> > For the US military, starlink has already allowed two antenna/terminal
>> > manufacturers to connect to the network.
>> >
>> > Ball aerospace for aircraft.
>> >
>> > DUJUD(hope I got that right) for regular user terminals.
>> >
>> > Any antenna that connects with OneWeb should theoretically work apart
>> > from
>> > the DRM
>> >
>> > On Wed, Aug 30, 2023, 8:36 PM David Lang <david@lang.hm> wrote:
>> >
>> > > Exactly my thoughts (I haven't downloaded and read the full report
>> > > yet).
>> > > What
>> > > are they looking to do with this 'integration'? I can integrate my
>> > > starlink just
>> > > like any other ISP.
>> > >
>> > > or are they looking at the 'cell phones to orbit' functionality thats
>> > > due
>> > > to
>> > > roll out very suddently
>> > >
>> > > or are they looking for "intergration" as another way to say "force
>> > > SpaceX
>> > > to
>> > > open the specs for Starlink and allow other user terminals to interact
>> > > with the
>> > > Starlink satellites?
>> > >
>> > > The cynic in me says it's the latter.
>> > >
>> > > long term it may make sense to do this to some degree, but we are WAY
>> > > too
>> > > early
>> > > to define "Interoperability Standards" and block people from coming up
>> > > with
>> > > better ways to do things.
>> > >
>> > > the Apple vs SpaceX cellphone-to-satellite have completely different
>> > > ways
>> > > of
>> > > operating, and who wants to tell all the Apple people that their way
>> > > isn't
>> > > going
>> > > to be the standard (or worse, that it is and they have to give
>> > > everyone
>> > > else the
>> > > ability to use their currently proprietary protocol)
>> > >
>> > > David Lang
>> > >
>> > > On Wed, 30 Aug 2023, Inemesit Affia via Starlink wrote:
>> > >
>> > > > With the existence of solutions like OpenMTCProuter, SDWAN, policy
>> > > > based
>> > > > routing or any solution in general that allows combination in a
>> > > > sense of
>> > > > any number of IP links, I really don't see a point for specific
>> > > solutions.
>> > > > Can anyone enlighten me?
>> > > >
>> > > > For home users an issue may be IP blocks for certain services like
>> > > Netflix
>> > > > when the egress is out of a VPN or cloud provider richer than a
>> > > residential
>> > > > provider
>> > > >
>> > > > On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
>> > > > starlink@lists.bufferbloat.net> wrote:
>> > > >
>> > > > >
>> > > > > Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>> > > > > > Here is a report which summarizes the outcome of the last
>> > > > > > Satellites
>> > > > > > conference
>> > > > > > [
>> > > > >
>> > > https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
>> > > > > ]
>> > > > > >
>> > > > > > The report highlights the two main hurdles against the
>> > > > > > integration of
>> > > > > > satellites and terrestrial networks: standardization and
>> > > > > > business
>> > > model.
>> > > > > >
>> > > > > > "/Most of the pushback against closer integration of terrestrial
>> > > > > > wireless and satellite networks revolved around standardization.
>> > > > > > This
>> > > > > > may just be growing pains and it likely reflects the relative
>> > > > > > positions of wireless and satellite along the maturity curve,
>> > > > > > but some
>> > > > > > of the speakers were arguing against standardization. The basis
>> > > > > > of
>> > > > > > this argument was that the mobile industry only understands
>> > > > > > standards,
>> > > > > > but the satellite industry is currently differentiating based on
>> > > > > > custom systems and capabilities. The feeling was that the
>> > > > > > satellite
>> > > > > > industry had focused on technology and not regulations or
>> > > > > > standards
>> > > > > > and changing that course would not be helpful to the industry in
>> > > > > > the
>> > > > > > short term. Timing is important in this analysis because almost
>> > > > > > everyone agreed that at some point, standardization would be a
>> > > > > > good
>> > > > > > thing, but the concern was the best way to get to the point in
>> > > > > > the
>> > > > > > future. The other interesting argument against closer
>> > > > > > integration
>> > > > > > between wireless and satellite had to do with the business
>> > > > > > model.
>> > > > > > Several speakers questioned where the customers would go as
>> > > > > > terrestrial and non-terrestrial networks become more integrated.
>> > > > > > The
>> > > > > > underlying issues seemed to include who is responsible for
>> > > > > > solving
>> > > > > > network issues and perhaps more importantly, who recognizes the
>> > > > > > revenue. These issues seem, perhaps a bit simplistically, to be
>> > > > > > similar to early wireless roaming issues. While these issues
>> > > > > > created
>> > > > > > turbulence in the wireless market, they were solved and that is
>> > > > > > probably a template to address these challenges for the wireless
>> > > > > > and
>> > > > > > satellite operators."/
>> > > > > > /
>> > > > > > /
>> > > > > > Comments?
>> > > > >
>> > > > >
>> > > > > It is an interesting report.
>> > > > >
>> > > > > For standardisation standpoint, it seems SDOs do push towards
>> > > > > integration of 5G/6G and satcom; there are strong initiatives at
>> > > > > least
>> > > > > at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.
>> > > > > But
>> > > > > these are SDOs traditionally oriented to land communications,
>> > > > > rather
>> > > > > than space satcom.
>> > > > >
>> > > > > I wonder whether space satcom traditional SDOs (which ones?) have
>> > > > > initiated work towards integration with 5G/6G and other land-based
>> > > > > Internet?
>> > > > >
>> > > > > Alex
>> > > > >
>> > > > > >
>> > > > > > Hesham
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230902/9209f929/attachment-0001.html>
>
> ------------------------------

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

[David Lang]

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

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 <starlink@lists.bufferbloat.net>
> Reply-To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> 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 <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
>>
>> _______________________________________________
>> 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
>

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

[Alexandre Petrescu]

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 <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
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

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

[David Lang]

[-- 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

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

[David Fernández]

"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>
>

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

[Alexandre Petrescu]

Le 03/09/2023 à 03:03, David Fernández via Starlink a écrit :
> It seems that Starlink follows this norm, although it does not reflect
> the entire Starlink system specification:
> https://www.etsi.org/deliver/etsi_en/303900_303999/303981/01.02.00_30/en_303981v010200v.pdf

How comes?  Is it because a starlink box might have that printed on a 
label?  Or the user manual?  Or the FCC application?

What reflects the entire Starlink specification?

>
> Then, for the ISL, I suppose they are following this:
> https://www.sda.mil/wp-content/uploads/2022/04/SDA-OCT-Standard-v3.0.pdf

Interesting.  It is an optics specification.  Also kepler refers to the 
same document.

If starlink uses that optical system for ISL then it is worth noting.

Remark also that that spec tells there is Ethernet in there.  It might 
be that because of that IP might be used.

Alex

>
>> Date: Fri, 1 Sep 2023 17:27:30 +0100
>> From: Inemesit Affia <inemesitaffia@gmail.com>
>> To: David Lang <david@lang.hm>
>> Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>,
>> 	starlink@lists.bufferbloat.net
>> Subject: Re: [Starlink] Main hurdles against the Integration of
>> 	Satellites and Terrestial Networks
>> Message-ID:
>> 	<CAJEhh70CMSk_WAmd9sgXfMDoWZhhz5uPAU=d5UG3rW5XFkw1KQ@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> For the US military, starlink has already allowed two antenna/terminal
>> manufacturers to connect to the network.
>>
>> Ball aerospace for aircraft.
>>
>> DUJUD(hope I got that right) for regular user terminals.
>>
>> Any antenna that connects with OneWeb should theoretically work apart from
>> the DRM
>>
>> On Wed, Aug 30, 2023, 8:36 PM David Lang <david@lang.hm> wrote:
>>
>>> Exactly my thoughts (I haven't downloaded and read the full report yet).
>>> What
>>> are they looking to do with this 'integration'? I can integrate my
>>> starlink just
>>> like any other ISP.
>>>
>>> or are they looking at the 'cell phones to orbit' functionality thats due
>>> to
>>> roll out very suddently
>>>
>>> or are they looking for "intergration" as another way to say "force SpaceX
>>> to
>>> open the specs for Starlink and allow other user terminals to interact
>>> with the
>>> Starlink satellites?
>>>
>>> The cynic in me says it's the latter.
>>>
>>> long term it may make sense to do this to some degree, but we are WAY too
>>> early
>>> to define "Interoperability Standards" and block people from coming up
>>> with
>>> better ways to do things.
>>>
>>> the Apple vs SpaceX cellphone-to-satellite have completely different ways
>>> of
>>> operating, and who wants to tell all the Apple people that their way isn't
>>> going
>>> to be the standard (or worse, that it is and they have to give everyone
>>> else the
>>> ability to use their currently proprietary protocol)
>>>
>>> David Lang
>>>
>>> On Wed, 30 Aug 2023, Inemesit Affia via Starlink wrote:
>>>
>>>> With the existence of solutions like OpenMTCProuter, SDWAN, policy based
>>>> routing or any solution in general that allows combination in a sense of
>>>> any number of IP links, I really don't see a point for specific
>>> solutions.
>>>> Can anyone enlighten me?
>>>>
>>>> For home users an issue may be IP blocks for certain services like
>>> Netflix
>>>> when the egress is out of a VPN or cloud provider richer than a
>>> residential
>>>> provider
>>>>
>>>> On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
>>>> starlink@lists.bufferbloat.net> wrote:
>>>>
>>>>> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>>>>>> Here is a report which summarizes the outcome of the last Satellites
>>>>>> conference
>>>>>> [
>>> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
>>>>> ]
>>>>>> The report highlights the two main hurdles against the integration of
>>>>>> satellites and terrestrial networks: standardization and business
>>> model.
>>>>>> "/Most of the pushback against closer integration of terrestrial
>>>>>> wireless and satellite networks revolved around standardization. This
>>>>>> may just be growing pains and it likely reflects the relative
>>>>>> positions of wireless and satellite along the maturity curve, but some
>>>>>> of the speakers were arguing against standardization. The basis of
>>>>>> this argument was that the mobile industry only understands standards,
>>>>>> but the satellite industry is currently differentiating based on
>>>>>> custom systems and capabilities. The feeling was that the satellite
>>>>>> industry had focused on technology and not regulations or standards
>>>>>> and changing that course would not be helpful to the industry in the
>>>>>> short term. Timing is important in this analysis because almost
>>>>>> everyone agreed that at some point, standardization would be a good
>>>>>> thing, but the concern was the best way to get to the point in the
>>>>>> future. The other interesting argument against closer integration
>>>>>> between wireless and satellite had to do with the business model.
>>>>>> Several speakers questioned where the customers would go as
>>>>>> terrestrial and non-terrestrial networks become more integrated. The
>>>>>> underlying issues seemed to include who is responsible for solving
>>>>>> network issues and perhaps more importantly, who recognizes the
>>>>>> revenue. These issues seem, perhaps a bit simplistically, to be
>>>>>> similar to early wireless roaming issues. While these issues created
>>>>>> turbulence in the wireless market, they were solved and that is
>>>>>> probably a template to address these challenges for the wireless and
>>>>>> satellite operators."/
>>>>>> /
>>>>>> /
>>>>>> Comments?
>>>>>
>>>>> It is an interesting report.
>>>>>
>>>>> For standardisation standpoint, it seems SDOs do push towards
>>>>> integration of 5G/6G and satcom; there are strong initiatives at least
>>>>> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
>>>>> these are SDOs traditionally oriented to land communications, rather
>>>>> than space satcom.
>>>>>
>>>>> I wonder whether space satcom traditional SDOs (which ones?) have
>>>>> initiated work towards integration with 5G/6G and other land-based
>>>>> Internet?
>>>>>
>>>>> Alex
>>>>>
>>>>>> Hesham
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

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

[Mike Puchol]

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

The ETSI standard you reference is a generic framework for testing & measuring earth stations connecting to NGSO systems, so they may be using it, but it’s not mandatory. In any case, the standard doesn’t have any effect on the RF characteristics, the interoperability, etc.

Regarding ISL, I would doubt they use the SDA OCT standard, except maybe for Starshield payloads. The SDA standard requires beaconless PAT without a side channel to sync the two OCTs, which makes things much harder. Acquisition times are longer, and initial pointing requires extremely accurate knowledege of the position of the other side, which greatly increases cost.

Best,

Mike
On Sep 2, 2023 at 18:03 -0700, David Fernández via Starlink <starlink@lists.bufferbloat.net>, wrote:
> It seems that Starlink follows this norm, although it does not reflect
> the entire Starlink system specification:
> https://www.etsi.org/deliver/etsi_en/303900_303999/303981/01.02.00_30/en_303981v010200v.pdf
>
> Then, for the ISL, I suppose they are following this:
> https://www.sda.mil/wp-content/uploads/2022/04/SDA-OCT-Standard-v3.0.pdf
>
> > Date: Fri, 1 Sep 2023 17:27:30 +0100
> > From: Inemesit Affia <inemesitaffia@gmail.com>
> > To: David Lang <david@lang.hm>
> > Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>,
> > starlink@lists.bufferbloat.net
> > Subject: Re: [Starlink] Main hurdles against the Integration of
> > Satellites and Terrestial Networks
> > Message-ID:
> > <CAJEhh70CMSk_WAmd9sgXfMDoWZhhz5uPAU=d5UG3rW5XFkw1KQ@mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > For the US military, starlink has already allowed two antenna/terminal
> > manufacturers to connect to the network.
> >
> > Ball aerospace for aircraft.
> >
> > DUJUD(hope I got that right) for regular user terminals.
> >
> > Any antenna that connects with OneWeb should theoretically work apart from
> > the DRM
> >
> > On Wed, Aug 30, 2023, 8:36 PM David Lang <david@lang.hm> wrote:
> >
> > > Exactly my thoughts (I haven't downloaded and read the full report yet).
> > > What
> > > are they looking to do with this 'integration'? I can integrate my
> > > starlink just
> > > like any other ISP.
> > >
> > > or are they looking at the 'cell phones to orbit' functionality thats due
> > > to
> > > roll out very suddently
> > >
> > > or are they looking for "intergration" as another way to say "force SpaceX
> > > to
> > > open the specs for Starlink and allow other user terminals to interact
> > > with the
> > > Starlink satellites?
> > >
> > > The cynic in me says it's the latter.
> > >
> > > long term it may make sense to do this to some degree, but we are WAY too
> > > early
> > > to define "Interoperability Standards" and block people from coming up
> > > with
> > > better ways to do things.
> > >
> > > the Apple vs SpaceX cellphone-to-satellite have completely different ways
> > > of
> > > operating, and who wants to tell all the Apple people that their way isn't
> > > going
> > > to be the standard (or worse, that it is and they have to give everyone
> > > else the
> > > ability to use their currently proprietary protocol)
> > >
> > > David Lang
> > >
> > > On Wed, 30 Aug 2023, Inemesit Affia via Starlink wrote:
> > >
> > > > With the existence of solutions like OpenMTCProuter, SDWAN, policy based
> > > > routing or any solution in general that allows combination in a sense of
> > > > any number of IP links, I really don't see a point for specific
> > > solutions.
> > > > Can anyone enlighten me?
> > > >
> > > > For home users an issue may be IP blocks for certain services like
> > > Netflix
> > > > when the egress is out of a VPN or cloud provider richer than a
> > > residential
> > > > provider
> > > >
> > > > On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
> > > > starlink@lists.bufferbloat.net> wrote:
> > > >
> > > > >
> > > > > Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
> > > > > > Here is a report which summarizes the outcome of the last Satellites
> > > > > > conference
> > > > > > [
> > > > >
> > > https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
> > > > > ]
> > > > > >
> > > > > > The report highlights the two main hurdles against the integration of
> > > > > > satellites and terrestrial networks: standardization and business
> > > model.
> > > > > >
> > > > > > "/Most of the pushback against closer integration of terrestrial
> > > > > > wireless and satellite networks revolved around standardization. This
> > > > > > may just be growing pains and it likely reflects the relative
> > > > > > positions of wireless and satellite along the maturity curve, but some
> > > > > > of the speakers were arguing against standardization. The basis of
> > > > > > this argument was that the mobile industry only understands standards,
> > > > > > but the satellite industry is currently differentiating based on
> > > > > > custom systems and capabilities. The feeling was that the satellite
> > > > > > industry had focused on technology and not regulations or standards
> > > > > > and changing that course would not be helpful to the industry in the
> > > > > > short term. Timing is important in this analysis because almost
> > > > > > everyone agreed that at some point, standardization would be a good
> > > > > > thing, but the concern was the best way to get to the point in the
> > > > > > future. The other interesting argument against closer integration
> > > > > > between wireless and satellite had to do with the business model.
> > > > > > Several speakers questioned where the customers would go as
> > > > > > terrestrial and non-terrestrial networks become more integrated. The
> > > > > > underlying issues seemed to include who is responsible for solving
> > > > > > network issues and perhaps more importantly, who recognizes the
> > > > > > revenue. These issues seem, perhaps a bit simplistically, to be
> > > > > > similar to early wireless roaming issues. While these issues created
> > > > > > turbulence in the wireless market, they were solved and that is
> > > > > > probably a template to address these challenges for the wireless and
> > > > > > satellite operators."/
> > > > > > /
> > > > > > /
> > > > > > Comments?
> > > > >
> > > > >
> > > > > It is an interesting report.
> > > > >
> > > > > For standardisation standpoint, it seems SDOs do push towards
> > > > > integration of 5G/6G and satcom; there are strong initiatives at least
> > > > > at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction. But
> > > > > these are SDOs traditionally oriented to land communications, rather
> > > > > than space satcom.
> > > > >
> > > > > I wonder whether space satcom traditional SDOs (which ones?) have
> > > > > initiated work towards integration with 5G/6G and other land-based
> > > > > Internet?
> > > > >
> > > > > Alex
> > > > >
> > > > > >
> > > > > > Hesham
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

[-- Attachment #2: Type: text/html, Size: 8119 bytes --]

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

[David Fernández]

It seems that Starlink follows this norm, although it does not reflect
the entire Starlink system specification:
https://www.etsi.org/deliver/etsi_en/303900_303999/303981/01.02.00_30/en_303981v010200v.pdf

Then, for the ISL, I suppose they are following this:
https://www.sda.mil/wp-content/uploads/2022/04/SDA-OCT-Standard-v3.0.pdf

> Date: Fri, 1 Sep 2023 17:27:30 +0100
> From: Inemesit Affia <inemesitaffia@gmail.com>
> To: David Lang <david@lang.hm>
> Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>,
> 	starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Main hurdles against the Integration of
> 	Satellites and Terrestial Networks
> Message-ID:
> 	<CAJEhh70CMSk_WAmd9sgXfMDoWZhhz5uPAU=d5UG3rW5XFkw1KQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> For the US military, starlink has already allowed two antenna/terminal
> manufacturers to connect to the network.
>
> Ball aerospace for aircraft.
>
> DUJUD(hope I got that right) for regular user terminals.
>
> Any antenna that connects with OneWeb should theoretically work apart from
> the DRM
>
> On Wed, Aug 30, 2023, 8:36 PM David Lang <david@lang.hm> wrote:
>
>> Exactly my thoughts (I haven't downloaded and read the full report yet).
>> What
>> are they looking to do with this 'integration'? I can integrate my
>> starlink just
>> like any other ISP.
>>
>> or are they looking at the 'cell phones to orbit' functionality thats due
>> to
>> roll out very suddently
>>
>> or are they looking for "intergration" as another way to say "force SpaceX
>> to
>> open the specs for Starlink and allow other user terminals to interact
>> with the
>> Starlink satellites?
>>
>> The cynic in me says it's the latter.
>>
>> long term it may make sense to do this to some degree, but we are WAY too
>> early
>> to define "Interoperability Standards" and block people from coming up
>> with
>> better ways to do things.
>>
>> the Apple vs SpaceX cellphone-to-satellite have completely different ways
>> of
>> operating, and who wants to tell all the Apple people that their way isn't
>> going
>> to be the standard (or worse, that it is and they have to give everyone
>> else the
>> ability to use their currently proprietary protocol)
>>
>> David Lang
>>
>> On Wed, 30 Aug 2023, Inemesit Affia via Starlink wrote:
>>
>> > With the existence of solutions like OpenMTCProuter, SDWAN, policy based
>> > routing or any solution in general that allows combination in a sense of
>> > any number of IP links, I really don't see a point for specific
>> solutions.
>> > Can anyone enlighten me?
>> >
>> > For home users an issue may be IP blocks for certain services like
>> Netflix
>> > when the egress is out of a VPN or cloud provider richer than a
>> residential
>> > provider
>> >
>> > On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
>> > starlink@lists.bufferbloat.net> wrote:
>> >
>> >>
>> >> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>> >>> Here is a report which summarizes the outcome of the last Satellites
>> >>> conference
>> >>> [
>> >>
>> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
>> >> ]
>> >>>
>> >>> The report highlights the two main hurdles against the integration of
>> >>> satellites and terrestrial networks: standardization and business
>> model.
>> >>>
>> >>> "/Most of the pushback against closer integration of terrestrial
>> >>> wireless and satellite networks revolved around standardization. This
>> >>> may just be growing pains and it likely reflects the relative
>> >>> positions of wireless and satellite along the maturity curve, but some
>> >>> of the speakers were arguing against standardization. The basis of
>> >>> this argument was that the mobile industry only understands standards,
>> >>> but the satellite industry is currently differentiating based on
>> >>> custom systems and capabilities. The feeling was that the satellite
>> >>> industry had focused on technology and not regulations or standards
>> >>> and changing that course would not be helpful to the industry in the
>> >>> short term. Timing is important in this analysis because almost
>> >>> everyone agreed that at some point, standardization would be a good
>> >>> thing, but the concern was the best way to get to the point in the
>> >>> future. The other interesting argument against closer integration
>> >>> between wireless and satellite had to do with the business model.
>> >>> Several speakers questioned where the customers would go as
>> >>> terrestrial and non-terrestrial networks become more integrated. The
>> >>> underlying issues seemed to include who is responsible for solving
>> >>> network issues and perhaps more importantly, who recognizes the
>> >>> revenue. These issues seem, perhaps a bit simplistically, to be
>> >>> similar to early wireless roaming issues. While these issues created
>> >>> turbulence in the wireless market, they were solved and that is
>> >>> probably a template to address these challenges for the wireless and
>> >>> satellite operators."/
>> >>> /
>> >>> /
>> >>> Comments?
>> >>
>> >>
>> >> It is an interesting report.
>> >>
>> >> For standardisation standpoint, it seems SDOs do push towards
>> >> integration of 5G/6G and satcom; there are strong initiatives at least
>> >> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
>> >> these are SDOs traditionally oriented to land communications, rather
>> >> than space satcom.
>> >>
>> >> I wonder whether space satcom traditional SDOs (which ones?) have
>> >> initiated work towards integration with 5G/6G and other land-based
>> >> Internet?
>> >>
>> >> Alex
>> >>
>> >>>
>> >>> Hesham

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

[David Fernández]

I have not seen a report, it is a couple of web pages to read, isn't it?

Just my two cents:
"Standards are the distilled wisdom of people with expertise in their
subject matter and who know the needs of the organizations they
represent – people such as manufacturers, sellers, buyers, customers,
trade associations, users or regulators.
Standards are knowledge. They are powerful tools that can help drive
innovation and increase productivity. They can make organizations more
successful and people’s everyday lives easier, safer and healthier."
https://www.bsigroup.com/en-GB/standards/Information-about-standards/what-is-a-standard

Look to what is reported about Rohde & Schwarz and Satixfy in the
Satellite 2023 about the DVB-S2X and DVB-RCS2 standards. I think that
the satellite industry has standards (DVB-S2X being the most notable
example), and these standards are not going to be replaced by 5G NTN,
3GPP ones, so easily. In any case, the 3GPP has defined since release
16 the N3IWF and the ATSSS with MPTCP, which is kind of standardized
way of doing the same that can be done with SDWAN (propietary
technologies): https://romars.tech/en/pubblications/n3iwf/
https://romars.tech/en/pubblications/atsss/
In the case of 5G NTN, if I think that the idea is that the terminal
is doing roaming between the terrestrial and the satellite network,
managing the links as when you have multiple SIM cards in the mobile.

Finally, related to the use of standards, I have been recently very
disappointed to see that this service is using a non-standard return
link, preventing Router Freedom for SATCOM users:
https://fsfe.org/activities/routers/routers.en.html

New GEO based Internet access for rural areas in Spain (Hispasat)
sponsored by Government

Up to 4 million subscribers are entitled all around the country, in
areas where there is not any terrestrial network providing Internet
access at least at 50 Mbit/s, and there are quite a few spots:
https://experience.arcgis.com/experience/a1efc4ec0e4b42ad90274ad6febb1608/

100 Mbit/s downlink DVB-S2X, non-standard? MF-TDMA uplink at 5 Mbit/s
/ 10 Mbit/s

Hughes modems: https://conectate35.es/#equipamiento

35 euros/month, 150 GB.

Average total (monthly?) maximum latency: 690 ms (two way?) (VoIP compatible)

99.5% availability

https://conectate35.es/#servicio

Regards,

David

> Date: Wed, 30 Aug 2023 12:35:59 -0700 (PDT)
> From: David Lang <david@lang.hm>
> To: Inemesit Affia <inemesitaffia@gmail.com>
> Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>,
> 	starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Main hurdles against the Integration of
> 	Satellites and Terrestial Networks
> Message-ID: <4o116qp9-6108-91r8-pn91-o37o6629npqo@ynat.uz>
> Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"
>
> Exactly my thoughts (I haven't downloaded and read the full report yet).
> What
> are they looking to do with this 'integration'? I can integrate my starlink
> just
> like any other ISP.
>
> or are they looking at the 'cell phones to orbit' functionality thats due to
> roll out very suddently
>
> or are they looking for "intergration" as another way to say "force SpaceX
> to
> open the specs for Starlink and allow other user terminals to interact with
> the
> Starlink satellites?
>
> The cynic in me says it's the latter.
>
> long term it may make sense to do this to some degree, but we are WAY too
> early
> to define "Interoperability Standards" and block people from coming up with
> better ways to do things.
>
> the Apple vs SpaceX cellphone-to-satellite have completely different ways of
> operating, and who wants to tell all the Apple people that their way isn't
> going
> to be the standard (or worse, that it is and they have to give everyone else
> the
> ability to use their currently proprietary protocol)
>
> David Lang
>
> On Wed, 30 Aug 2023, Inemesit Affia via Starlink wrote:
>
>> With the existence of solutions like OpenMTCProuter, SDWAN, policy based
>> routing or any solution in general that allows combination in a sense of
>> any number of IP links, I really don't see a point for specific solutions.
>> Can anyone enlighten me?
>>
>> For home users an issue may be IP blocks for certain services like Netflix
>> when the egress is out of a VPN or cloud provider richer than a
>> residential
>> provider
>>
>> On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
>> starlink@lists.bufferbloat.net> wrote:
>>
>>>
>>> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>>>> Here is a report which summarizes the outcome of the last Satellites
>>>> conference
>>>> [
>>> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
>>> ]
>>>>
>>>> The report highlights the two main hurdles against the integration of
>>>> satellites and terrestrial networks: standardization and business model.
>>>>
>>>> "/Most of the pushback against closer integration of terrestrial
>>>> wireless and satellite networks revolved around standardization. This
>>>> may just be growing pains and it likely reflects the relative
>>>> positions of wireless and satellite along the maturity curve, but some
>>>> of the speakers were arguing against standardization. The basis of
>>>> this argument was that the mobile industry only understands standards,
>>>> but the satellite industry is currently differentiating based on
>>>> custom systems and capabilities. The feeling was that the satellite
>>>> industry had focused on technology and not regulations or standards
>>>> and changing that course would not be helpful to the industry in the
>>>> short term. Timing is important in this analysis because almost
>>>> everyone agreed that at some point, standardization would be a good
>>>> thing, but the concern was the best way to get to the point in the
>>>> future. The other interesting argument against closer integration
>>>> between wireless and satellite had to do with the business model.
>>>> Several speakers questioned where the customers would go as
>>>> terrestrial and non-terrestrial networks become more integrated. The
>>>> underlying issues seemed to include who is responsible for solving
>>>> network issues and perhaps more importantly, who recognizes the
>>>> revenue. These issues seem, perhaps a bit simplistically, to be
>>>> similar to early wireless roaming issues. While these issues created
>>>> turbulence in the wireless market, they were solved and that is
>>>> probably a template to address these challenges for the wireless and
>>>> satellite operators."/
>>>> /
>>>> /
>>>> Comments?
>>>
>>>
>>> It is an interesting report.
>>>
>>> For standardisation standpoint, it seems SDOs do push towards
>>> integration of 5G/6G and satcom; there are strong initiatives at least
>>> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
>>> these are SDOs traditionally oriented to land communications, rather
>>> than space satcom.
>>>
>>> I wonder whether space satcom traditional SDOs (which ones?) have
>>> initiated work towards integration with 5G/6G and other land-based
>>> Internet?
>>>
>>> Alex
>>>
>>>>
>>>> Hesham

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

[David Fernández]

The use of MPTCP on satellite links has been analyzed here (for
example) and the use of PEPs in GEO satellite links prevent the use of
MPTCP:
https://datatracker.ietf.org/meeting/106/materials/slides-106-mptcp-mptcp-satellite-01#page=13&zoom=auto,-91,32

Another option could be MPQUIC (still in development AFAIK),

I have been told in the past that a tighter integration of satellite
and terrestrial networks is required mainly for business purposes
(billing).

Regards,

David

> Date: Wed, 30 Aug 2023 17:51:37 +0100
> From: Inemesit Affia <inemesitaffia@gmail.com>
> To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
> Cc: starlink@lists.bufferbloat.net
> Subject: Re: [Starlink] Main hurdles against the Integration of
> 	Satellites and Terrestial Networks
> Message-ID:
> 	<CAJEhh73R-9hZ3_C6ause9GezdHKPMrvtmHeodoykN6fMZgqP6Q@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> With the existence of solutions like OpenMTCProuter, SDWAN, policy based
> routing or any solution in general that allows combination in a sense of
> any number of IP links, I really don't see a point for specific solutions.
> Can anyone enlighten me?
>
> For home users an issue may be IP blocks for certain services like Netflix
> when the egress is out of a VPN or cloud provider richer than a residential
> provider
>
> On Wed, Aug 30, 2023, 2:57 PM Alexandre Petrescu via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>>
>> Le 30/08/2023 à 14:10, Hesham ElBakoury via Starlink a écrit :
>> > Here is a report which summarizes the outcome of the last Satellites
>> > conference
>> > [
>> https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
>> ]
>> >
>> > The report highlights the two main hurdles against the integration of
>> > satellites and terrestrial networks: standardization and business model.
>> >
>> > "/Most of the pushback against closer integration of terrestrial
>> > wireless and satellite networks revolved around standardization. This
>> > may just be growing pains and it likely reflects the relative
>> > positions of wireless and satellite along the maturity curve, but some
>> > of the speakers were arguing against standardization. The basis of
>> > this argument was that the mobile industry only understands standards,
>> > but the satellite industry is currently differentiating based on
>> > custom systems and capabilities. The feeling was that the satellite
>> > industry had focused on technology and not regulations or standards
>> > and changing that course would not be helpful to the industry in the
>> > short term. Timing is important in this analysis because almost
>> > everyone agreed that at some point, standardization would be a good
>> > thing, but the concern was the best way to get to the point in the
>> > future. The other interesting argument against closer integration
>> > between wireless and satellite had to do with the business model.
>> > Several speakers questioned where the customers would go as
>> > terrestrial and non-terrestrial networks become more integrated. The
>> > underlying issues seemed to include who is responsible for solving
>> > network issues and perhaps more importantly, who recognizes the
>> > revenue. These issues seem, perhaps a bit simplistically, to be
>> > similar to early wireless roaming issues. While these issues created
>> > turbulence in the wireless market, they were solved and that is
>> > probably a template to address these challenges for the wireless and
>> > satellite operators."/
>> > /
>> > /
>> > Comments?
>>
>>
>> It is an interesting report.
>>
>> For standardisation standpoint, it seems SDOs do push towards
>> integration of 5G/6G and satcom; there are strong initiatives at least
>> at 3GPP (NTN WI proposals) and IETF (TVR WG) in that direction.  But
>> these are SDOs traditionally oriented to land communications, rather
>> than space satcom.
>>
>> I wonder whether space satcom traditional SDOs (which ones?) have
>> initiated work towards integration with 5G/6G and other land-based
>> Internet?
>>
>> Alex
>>
>> >
>> > Hesham
>> >

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

[Hesham ElBakoury]

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

Here is a report which summarizes the outcome of the last Satellites
conference  [
https://www.microwavejournal.com/articles/39841-satellite-2023-summary-linking-up
]

The report highlights the two main hurdles against the integration of
satellites and terrestrial networks: *standardization and business model.*

"*Most of the pushback against closer integration of terrestrial wireless
and satellite networks revolved around standardization. This may just be
growing pains and it likely reflects the relative positions of wireless and
satellite along the maturity curve, but some of the speakers were arguing
against standardization. The basis of this argument was that the mobile
industry only understands standards, but the satellite industry is
currently differentiating based on custom systems and capabilities. The
feeling was that the satellite industry had focused on technology and not
regulations or standards and changing that course would not be helpful to
the industry in the short term. Timing is important in this analysis
because almost everyone agreed that at some point, standardization would be
a good thing, but the concern was the best way to get to the point in the
future. The other interesting argument against closer integration between
wireless and satellite had to do with the business model. Several speakers
questioned where the customers would go as terrestrial and non-terrestrial
networks become more integrated. The underlying issues seemed to include
who is responsible for solving network issues and perhaps more importantly,
who recognizes the revenue. These issues seem, perhaps a bit
simplistically, to be similar to early wireless roaming issues. While these
issues created turbulence in the wireless market, they were solved and that
is probably a template to address these challenges for the wireless and
satellite operators."*

Comments?

Hesham

[-- Attachment #2: Type: text/html, Size: 2237 bytes --]