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