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 C77753B29E for ; Wed, 27 Oct 2021 03:03:46 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id 88C1B10FA49; Wed, 27 Oct 2021 00:03:45 -0700 (PDT) Date: Wed, 27 Oct 2021 00:03:41 -0700 (PDT) From: David Lang To: Ulrich Speidel cc: starlink@lists.bufferbloat.net In-Reply-To: Message-ID: <33r3s281-7681-o576-9o66-ss827n15r327@ynat.uz> References: <28034.1635270711@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="===============8364340417273524362==" 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: Wed, 27 Oct 2021 07:03:47 -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. --===============8364340417273524362== Content-Type: text/plain; format=flowed; charset=US-ASCII On Wed, 27 Oct 2021, Ulrich Speidel wrote: > - 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. But it's still a lot of number crunching on a bird. Another > option would be for each satellite to compute a great circle direction to the > target cell and then forward to whichever neighbour satellite comes closest > to being along that route. Remember, IP routing doesn't require anybody have a global view of the network, just knowlege of nearby nodes. So the satellite needs to know what are good next hops to send traffic to that's headed in different directions, not global knowledge of the entire constellation. This doesn't require that all satellites be able to send in all directions. with lots of satellites in range, they could cycle between the first sending north, the second east, the third south, the fourth west... A key question to me is how many lasers, how fast they can be redirected to different satellites, and how many different satellites the detectors can receive from at one time. I'd hope that there are at least two lasers, so that they can transmit to the next hop and ack to the receiver without having to spin a laser 180. It also doesn't require that the satellite send to the nearst node in that direction (if longer distance traffic can be detected, you would want to send to a further away next hop to reduce the number of hops) They could even have a satellite varient that has more lasers/detectors and fewer RF antennas to connect to the ground to be dedicated to routing (especially as they launch satellites to different altitudes, nodes at higher altitudes could be optimized for long-distance hops) With only 'nearby' node knowledge needed, I could see low-power omnidirectional RF beacons being used for nodes to advertise their existance and routing config to the network. I expect that if they were doing this, that it would show up in their FCC filings and everyone would be talking about it, but it's a thought for future versions. All of this requies some way to tell from the packet where on earth (or in space) the destination is. If you tunnel over IPv6, you can have enough IPs to allocate them based on lat/long/ground/orbit so that the routing nodes (which know where they are) can know what direction to send things. Given the existance of mobile endpoints (vehicles, aircraft, spacecraft) this starts sounding like the mobile IP problem (how can you continue a persistant connection when moving from netowrk to network), but since all the entry/exit points are under their control, you can tunnel around and have a protocol to reconfigure the tunnels as endpoints move. David Lang --===============8364340417273524362== Content-Type: text/plain; CHARSET=utf-8 Content-Transfer-Encoding: BASE64 Content-ID: <76no6pr-r579-9q14-rr90-2933pqs5o6s@ynat.uz> Content-Description: Content-Disposition: INLINE X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU3Rhcmxpbmsg bWFpbGluZyBsaXN0ClN0YXJsaW5rQGxpc3RzLmJ1ZmZlcmJsb2F0Lm5ldApodHRwczovL2xpc3Rz LmJ1ZmZlcmJsb2F0Lm5ldC9saXN0aW5mby9zdGFybGluawo= --===============8364340417273524362==--