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 5130D3B29E for ; Mon, 17 Apr 2023 14:55:48 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id EDD75186C25; Mon, 17 Apr 2023 11:55:46 -0700 (PDT) Date: Mon, 17 Apr 2023 11:55:46 -0700 (PDT) From: David Lang To: =?ISO-8859-15?Q?David_Fern=E1ndez?= cc: starlink In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="228850167-583701742-1681757746=:15245" Subject: Re: [Starlink] IXPs in space 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: Mon, 17 Apr 2023 18:55:48 -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. --228850167-583701742-1681757746=:15245 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT nobody else has had enough satellites in space to do real in space routing, so take anything you read about it that's not specifically referring to starlink as guesses/suggestions. David Lang On Mon, 17 Apr 2023, David Fernández via Starlink wrote: > Date: Mon, 17 Apr 2023 16:22:33 +0200 > From: David Fernández via Starlink > Reply-To: David Fernández > To: starlink > Subject: Re: [Starlink] IXPs in space > > Apologies in advance for any *profound* misunderstanding that could > trigger any nerves, although I am grateful for all the info being > shared. I will read this carefully: > https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf > > In the abstract, I read, at the end: "Low level mechanisms to support > these functions are justified only as performance enhancements." So, > every rule has its exceptions, like the PEPs for TCP performance > acceleration. > > "Adding those anycast addresses to the satellites would be transparent > to all users (assuming the satellites are operating at the IP layer, > the old bent-pipe approach did not, but once you have routing in space > via the laser links...)" Satellites being routers just because they > have ISL does not follow. Is there any satellite nowadays doing > routing in space? They do switching only (and not Ethernet switching). > Because of this I proposed the idea of the so called L2 snooping. It > is a hack, somehow similar to the PEPs to accelerate TCP, but in this > case to accelerate DNS (not encrypted), without making satellites > routers, keeping them transparent as they are now. > > If it has not been done before by anybody is for a good reason, maybe. > Things like this did not have so much success, it seems: > https://en.wikipedia.org/wiki/Internet_Routing_in_Space > > "DNS is an easy thing to start with compared to most others." Even in > this case you are going to find a lot of issues to do it with > transparent satellites, even with GEO satellites, where the gain could > be bigger and things simpler than with fast moving LEO satellites. > > "bent pipe for normal operations doesn't mean that you can't watch for > an anycast address to serve locally." This is what I was suggesting, > you sniff packets in the satellite uplink and answer anycast DNS > queries directly from satellite, if you see any, cutting RTT by a > half. > > Regards, > > David > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink --228850167-583701742-1681757746=:15245--