[Starlink] thinking about the laser links again

Thu Oct 28 22:38:41 EDT 2021

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

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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20211028/26f5f7a2/attachment-0001.html>