[Starlink] thinking about the laser links again

Thu Oct 28 23:08:12 EDT 2021

On Thu, 28 Oct 2021, Steve Crocker wrote:

> Why wouldn't they make it completely IPv6???

Because IPv4 only services still exist.

For example, try to find a payment service that does IPv6 (for the Scale 
conference, that is the only part of our infrastructure that must be IPv4, so 
we've been looking for a few years)

David Lang

> Steve
>
> On Thu, Oct 28, 2021 at 9:12 PM Dave Taht <dave.taht at gmail.com> wrote:
>
>> I spent some time today looking over the job listings for clues (
>> https://www.spacex.com/careers/index.html?search=linux ) BGP/ISIS
>> keeps cropping up. It really also looks like they are inventing their
>> own SDN along the way. And: their public BGP table has gained a bunch
>> of ipv4/21s lately with a few users reporting a routable IP for a few
>> days or weeks. I do hope they find a ipv4/12 somewhere or better, as I
>> think they've discovered CGNs are not particularly fun, and their
>> projected growth for the next year or two would be within that, (and
>> one fantasy I harbor is they peer with a bunch of outback BGP AS
>> holders with a "pro" service)
>>
>> I've been trying for a few years to get some industry interested in
>> leveraging 240/4 (at least within their CGN for dishy to dishy comms),
>> there's a preso on it at the upcoming ietf intarea:
>> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/
>>
>> I know that's kind of a blue sky thing, but all the code has been
>> working for years in both bsd and linux, as well as in multiple big
>> iron routers, amazon, and in openwrt (where we tested it first). Just
>> someone with balls and $s needs to step up to become a space RIR and
>> try to make those addrs more routable than we already have....
>>
>> Anyway, good discussion on this thread!!! but all of you failed to
>> answer my humdinger question - *when* will they be able to route a
>> packet from new york to tokyo over the laser links? That kind of event
>> would be a world network latency record - right up there in
>> significance with the first inter-imp comms oct 29 1969:
>>
>>
>> https://en.wikipedia.org/wiki/ARPANET#/media/File:First-arpanet-imp-log.jpg
>>
>> On Thu, Oct 28, 2021 at 3:53 AM Mike Puchol <mike at starlink.sx> wrote:
>>>
>>> I cannot add more than the real experts on the networking / topology
>> side, but on the lasers themselves, a question was raised about multiple
>> links. The only way to do it economically is to use a single optical train
>> per link (includes laser TX and photon detector, mirrors, power control,
>> attenuators, etc.).
>>>
>>> I raised the idea of an FSOC “flashlight” to what could be counted as
>> people in the top 10 worldwide list of experts in the field. Here, a beam
>> would be made wide enough to have multiple “clients”, as for radio sector
>> antennas. The idea was quickly discarded for a number of reasons, the
>> principal being that you are spreading the photons so much that not enough
>> would reach the other side, at least at any meaningful distance.
>>>
>>> Photon detectors that could work are in the scientific instrument
>> category, thus really expensive.
>>>
>>> From photos, we know that each satellite has at least two lasers, so we
>> can assume at least in-plane communications.
>>>
>>> Best,
>>>
>>> Mike
>>> On Oct 28, 2021, 11:01 +0300, Ulrich Speidel <ulrich at cs.auckland.ac.nz>,
>> wrote:
>>>
>>> On 28/10/2021 7:29 am, Michael Richardson wrote:
>>>
>>> I guess the real question is: have you written the Hollywood Security
>>> Theatre
>>> script based upon this issues, and can I play the geek that explains
>>> this? :-)
>>>
>>> Sure!
>>>
>>>
>>> - Tell satellites where to send packets (in something along the
>>>
>>> lines of a
>>>
>>> long header, as in AX.25 for example). Then a sending ground station
>>>
>>> would
>>>
>>> need a complete almanach of the constellation and an idea as to
>>>
>>> where the
>>>
>>> receiving ground station is, and which satellite it would use for the
>>> downlink. Pros: The sending ground station can do all the number
>>>
>>> crunching on
>>>
>>> ground rather than space power. Cons:  Header size costs bandwidth.
>>>
>>>
>>> From what I understood, Starlink shipped some kind of comodity SDN
>> capable
>>> chip. So MPLS, or SRv6 ought to be easy, costing only a few bytes
>>> interpreted in hardware, and a path computation element on the ground
>>> should
>>> be able to deal with the calculation.
>>>
>>> It's a challenging situation perhaps because the network effectively gets
>>> rewired every few minutes, but ground based computation should be able to
>>> deal with the problem.
>>>
>>>
>>> That presumes that the ground station has complete topology information
>>> for the constellation, though. That includes knowing about defective
>>> satellites and lasers etc., birds deviating from assigned orbit.
>>>
>>> But in principle, I can see how that could work, yes.
>>>
>>>
>>> - Get the satellites to work out where stuff needs to be sent. If
>>>
>>> they were
>>>
>>> to use something like Bellman-Ford here, that would require an enormous
>>> amount of update traffic. Dijkstra would require complete topology
>>> information, which should in principle be computable from an
>>>
>>> almanach on the
>>>
>>> satellites.
>>>
>>>
>>> I think, but I might be wrong, that there is a pattern which repeats
>>> over and
>>> over again. Just need to update the mapping of which satellite is in
>> which
>>> position in the precomputed mesh. No need to send the entire mesh.
>>>
>>>
>>> Of course. Bellman-Ford & Co. all assume a network without such
>>> regularities. But you need to make use of those patterns in order to
>>> make things possible - whether you do source or hop-to-hop routing. And
>>> while the configuration of the network is indeed predictable at least
>>> for the near future, it's not simply repeating over and over again. The
>>> current constellation (if viewed in isolation) more or less runs in 95
>>> minute cycles. Earth rotates under the constellation, so the teleports
>>> only return to the same position with respect to the constellation when
>>> multiples of the length of a sidereal day coincide with multiples of 95
>>> minutes. Plus you may find that the Starlink constellation isn't
>>> perfectly regular either in its pattern.
>>>
>>>
>>>
>>> --
>>> ****************************************************************
>>> Dr. Ulrich Speidel
>>>
>>> School of Computer Science
>>>
>>> Room 303S.594 (City Campus)
>>> Ph: (+64-9)-373-7599 ext. 85282
>>>
>>> The University of Auckland
>>> ulrich at cs.auckland.ac.nz
>>> http://www.cs.auckland.ac.nz/~ulrich/
>>> ****************************************************************
>>>
>>>
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>>
>>> _______________________________________________
>>> Starlink mailing list
>>> Starlink at lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/starlink
>>
>>
>>
>> --
>> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
>>
>> Dave Täht CEO, TekLibre, LLC
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>
-------------- next part --------------
_______________________________________________
Starlink mailing list
Starlink at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink