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 090D43B2A4 for ; Sun, 16 Apr 2023 18:03:43 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id 2FF1E1867F4; Sun, 16 Apr 2023 15:03:42 -0700 (PDT) Date: Sun, 16 Apr 2023 15:03:42 -0700 (PDT) From: David Lang To: Ulrich Speidel cc: starlink@lists.bufferbloat.net In-Reply-To: Message-ID: <83qps6or-4574-n64r-6r95-71sp695q58p4@ynat.uz> References: MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="===============9217294623537370846==" Subject: Re: [Starlink] fiber 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: Sun, 16 Apr 2023 22:03:43 -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. --===============9217294623537370846== Content-Type: text/plain; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT On Mon, 17 Apr 2023, Ulrich Speidel via Starlink wrote: > On 17/04/2023 5:54 am, David Fernández via Starlink wrote: >> In case you put a DNS server in the satellite, so that it replies >> instead of a DNS server on ground, the RTT is reduced by half. >> >> The idea would be that the satellite inspects IP packets and when it >> detects a DNS query, instead of forwarding the packet to ground >> station, it just answers back to the sender of the query. > Understood - it's just that the gain you have from this is quite small. DNS > queries only happen the first time a host needs to resolve a name, and then > again after cache expiry much later, so they account for only a tiny fraction > of the traffic, and also for only a small amount of the total delay in page > loads. RTT isn't really the big issue in Starlink - yes it's larger than it > perhaps needs to be, and bufferbloat seems to be present, but compared to > GEO, it's now in the range seen for terrestrial Internet. DNS time is more significant than you think, due to the fact that so many websites pull data from many different locations, you end up with a lot of DNS queries when hitting a new site for the first time (and many of these queries are serial not parallel) so it adds quite a bit to the first rendering time of a page. >> CDNs or even datacenters (Cloud) in GEO or LEO is even more complex. > > Indeed. In so many ways. > > Mind though that CDNs are generally tied in with DNS nowadays, and there's > another snag: Take two users, Alice in the UK and Bob in New Zealand - pretty > much antipodean, using Starlink in bent-pipe configuration, i.e., their > traffic goes through, say, the London gateway in the UK and the Clevedon > gateway in NZ. Now imagine both trying to resolve the same CDN hostname some > time apart, but via the same satellite DNS as the satellite has moved from > the UK to NZ in the interim. Say Alice resolves first and gets the IP address > of a CDN server in the UK. If the satellite DNS now caches this, and Bob > queries the same hostname, he gets directed to a server in the UK literally a > world away instead of the Auckland one closest to him. So unless each > satellite carries a geolocated copy of the world's DNS entries with it and > makes a decision based on user location, you have a problem. This is true when the DNS answer is dynamic, but such cases also have short cache timeouts. Even with a 90 min orbit, a 15 min timeout would significantly lessen the impact (and I would expect that an orbital DNS would detect short timeouts and treat them as a signal to shorten the timeout even more) David Lang --===============9217294623537370846== Content-Type: text/plain; CHARSET=utf-8 Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: INLINE X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KU3Rhcmxpbmsg bWFpbGluZyBsaXN0ClN0YXJsaW5rQGxpc3RzLmJ1ZmZlcmJsb2F0Lm5ldApodHRwczovL2xpc3Rz LmJ1ZmZlcmJsb2F0Lm5ldC9saXN0aW5mby9zdGFybGluawo= --===============9217294623537370846==--