From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2972B3B2A4 for ; Thu, 28 Oct 2021 23:08:15 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id 4952F10FE5B; Thu, 28 Oct 2021 20:08:14 -0700 (PDT) Date: Thu, 28 Oct 2021 20:08:12 -0700 (PDT) From: David Lang To: Steve Crocker cc: Dave Taht , starlink@lists.bufferbloat.net In-Reply-To: Message-ID: <869538s1-742s-63q6-85sn-5n6913r79onn@ynat.uz> References: <28034.1635270711@localhost> <8007.1635359366@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="===============5999862969927277808==" Subject: Re: [Starlink] thinking about the laser links again X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2021 03:08:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============5999862969927277808== Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT 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 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 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 , >> 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@cs.auckland.ac.nz >>> http://www.cs.auckland.ac.nz/~ulrich/ >>> **************************************************************** >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> -- >> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw >> >> Dave Täht CEO, TekLibre, LLC >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink >> > --===============5999862969927277808== Content-Type: text/plain; CHARSET=utf-8 Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: INLINE X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU3Rhcmxpbmsg bWFpbGluZyBsaXN0ClN0YXJsaW5rQGxpc3RzLmJ1ZmZlcmJsb2F0Lm5ldApodHRwczovL2xpc3Rz LmJ1ZmZlcmJsb2F0Lm5ldC9saXN0aW5mby9zdGFybGluawo= --===============5999862969927277808==--