From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 933253B2A4 for ; Mon, 17 Apr 2023 01:50:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1681710650; i=moeller0@gmx.de; bh=tFv5Wb2EfvNQSrwxhbSlFTWbEDyptIb3PAjehYZt+ks=; h=X-UI-Sender-Class:Date:From:To:CC:Subject:In-Reply-To:References; b=n0UJ9z6pDLtlTmaqt5xfWaAchOkfqYlmAImKC62600YuN9gksxZrDm9i8l3/MEM/y 4LhUh+uw7x9y3Wu1B/mJCf6QqdAHfmYbjEMmvVihBuHXiROCIvgOWhErRQ0h2o+wRy t0zEsWWYVpbgGRV2OiOfoc9Pv9wW43Bi7AuAMqeg4K5JFYzZPYPQ/8p+D+sfgdv0HL ntHgfzpDplS9JWwywdknXA0fHbB1X5lkj7+aXtjTcy44PgXMCpSDsNVTJyg3NCeqr6 vTp5GDJaCd9ct7xGUi5iUiZl77rlNqy7gte4c7ncx4D0gyAwNE0lBBKeWnaDOkauFQ 4D5nmhXI3jVBA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [127.0.0.1] ([95.112.10.130]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N4z6k-1qV0Vp3Iyi-010qYp; Mon, 17 Apr 2023 07:50:49 +0200 Date: Mon, 17 Apr 2023 07:50:45 +0200 From: Sebastian Moeller To: David Lang , David Lang via Starlink , Ulrich Speidel CC: starlink@lists.bufferbloat.net User-Agent: K-9 Mail for Android In-Reply-To: References: <83qps6or-4574-n64r-6r95-71sp695q58p4@ynat.uz> <79dbfe96-b5d5-3475-8da9-a32c2f4d53b7@auckland.ac.nz> <5e2937ec-9d94-29ed-eac1-18d96db3a19e@auckland.ac.nz> <2sp7r191-q0o6-6543-0q78-p760477317o5@ynat.uz> Message-ID: <7A5EA39C-6C19-4FA4-9417-A287FE8C4B80@gmx.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----W2GCSVQ8EPHBHO3WOKSGYOYDSEWJ4P Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:uOj9PtlueHukjcyUkKkpjuU1eInrN6rPh3CBQuOaObMHW3ua0Dn aiUdla3HxiFHIBNBxzIPXCT9Tw9Csh71xQeLrBGUXQxrvicdnJYdUtJMY0NZjtqEH+HkGz5 Yy82VzkGus8ttHGxYXk3ZR1O5zj/H8LxrrsVtxob+VBZJbgaGaeHZMwk5aPG5/ezgU9hktA JaxBA0xIcvr/JrNMp1mLQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:6gLBFdWjhLA=;NvvWQLhtLNyu5DZFiLHuYC3LXlE JGJDMKC2LIAdvTJYH7A6KH13+rpLhfMu41M+pKLu59Rt9f+mT2yumMxRRhdZFyCC2T8PhEokp BcDj7x6WYhcngCPmTN3i0K1+quPLJYfQlATKCpLdzSCnsWP7N68yJZz6DU7bQ6RG1ujyK/k2w ZWK86YBv85S2YajDPODrqkVIBeZ1F/h+f1JkOHl3G+KXCl8L7nJouxKMCNToYV6VbgtTLi744 ugLKFSUB4a882PqIFO5uO9yNqQi7Fm+hL4sfp5i1vPGAxFj3rYU506T0kqLLBBAC/Eootqo6/ 0lzOa+V2apnpfe9GHPp4j2bRiuBFFEnbDlZQLO208uFiMJO9oGk4ZO6GQQoNcG9+6+hQuFOQQ Zto5sdQuPSSkTkvaRK8yPzAF8yI8NbxqGQfi19vsGJ96hc9MSLRQ4NZfu1856NYsXk3iSmCwQ k/Ng2tESgv98oM1XhsC4lo5WhpZhkKooG7C5loCC8o1nZpSQC9oJCbxJRwCCCO4WnrqwYgz5j 8FPQhKMC1WmL60i0ol2u7EXnD1ezN3zKbvZg7Sb9KQP8kRPym9IKqzo76Fpx41wtGF4mvdwFT N14wj21WRAb8iXXVUt0spa1rIheSMc1qruaTu2TbagU+VkHuToXTbIkcAoLFzfgdheEDj02d7 ckbeH34LX1QSyLDOY1UeMrG+FFsopcrYtEVlDeS4T5dgL5ZbUElJ3jfY15G9Z/sE/tZOvVj4b U8alSABULaRbsAmNv7T0n4Ea+WD0bgaYBDRUDBwmo1k4SdWrATZIyIolTk2vg9LWSjzgR7u5K gxqALwjbzOOLQeGTKRuwGwSynA2Cz+MzbPsRHzea2kuJvWEzkM5rA0mUY32ImPRJFRwihj15e nj2afMWxLuEJiDY5PEJWYGNNs91zvElT2fXM+KiVchtYN3p7njWOLUZHRT+xAKiLUzhC701cq 7lU3vijl2S41MD6H4WLGqjXVU9Y= 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: Mon, 17 Apr 2023 05:50:58 -0000 ------W2GCSVQ8EPHBHO3WOKSGYOYDSEWJ4P Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Interesting discussion=2E One other thing to keep in mind, some jurisdictions like the EU (in a broa= der sense, members typically crate their own EU compatible laws) legally ma= ndated DNS blocking of specific addresses is a thing, and our LEO DNS opera= tor likely would ned to honor these when over such regions making the whole= thing even more complicated and likely less attractive=2E=2E=2E On 17 April 2023 07:01:41 CEST, David Lang via Starlink wrote: >On Mon, 17 Apr 2023, Ulrich Speidel wrote: > >> On 17/04/2023 2:34 pm, David Lang wrote: >>> On Mon, 17 Apr 2023, Ulrich Speidel wrote: >>>=20 >>>> On 17/04/2023 1:04 pm, David Lang wrote: >>>>> I think it is going to be fairly common, but the beauty of the idea = is that you don't have to risk much to try it=2E Long lived DNS answers (an= d especially root servers and TLD servers) can trivially be mirrored to the= satellites, and you can experiment with caching to see what sort of hit ra= te you get=2E Even if you don't cache a lot of the CDN type traffic, it sho= uld still be a win to have the longer term stuff there=2E >>>>=20 >>>> Yes - but root servers and TLD servers also get cached a long time at= the clients=2E If each of your clients needs a root server and a few TLD l= ookups a day, it's not a huge gain in terms of performance=2E >>>>=20 >>>> It is however a significant step up in terms of complexity=2E E=2Eg= =2E, your satellite-based DNS would have to point you at the TLD server tha= t is topologically closest to your Starlink gateway, or risk a potentially = much longer RTT for the lookup=2E So you'd need to maintain a list of TLD i= nstances on your satellite-based DNS and return the one that corresponds to= what your gateway-based DNS would get=2E Sure possible but more complex th= an a bog standard DNS server in a fixed network=2E >>>=20 >>> really? I don't think the root and TLD servers do any geolocation, I t= hink they have fixed answers and rely on anycast addresses to find the clos= est one=2E Adding those anycast addresses to the satellites would be transp= oarent 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=2E=2E=2E) >>=20 >> So what you're suggesting would be a generic anycast-based set of DNS r= ecords to be kept on all satellites? >>=20 >> Hm=2E My terrestrial RTT to the closest 8=2E8=2E8=2E8 and 8=2E8=2E4=2E4= anycast DNS servers is about 28 ms, indicating that they're over in Austra= lia=2E No big surprise here, but that RTT isn't all too different from what= I'd expect from a Starlink connection=2E That compares to < 1 ms to my loc= al resolver=2E >>=20 >> Would an anycast-based generic DNS give us better RTT than a gateway-ba= sed DNS with full ability to cache local information? > >are you going to replicate the root server data to your gateway? what's a= fairly trivial amount of data for a server (including one in space) can be= a significant amount of data to store on an AP/gateway=2E If you have your= gateway caching it, you probably won't hit the space based servers in any = case=2E > >in part it would depend on how much the gateway gets turned off=2E (some = people do it for security, people who are mobile power things down to move) > >> Even with the laser links, it's worth repeating that most of Starlink's= operation is still bent pipe, and likely to continue to be so in future=2E= There is little evidence that the lasers are currently being used for anyt= hing but remote location access=2E >>=20 >> That said, bent pipe isn't the same as bent pipe=2E Analog telecom GEO = sats used to do physical layer bent pipe with the satellite incapable of IP= =2E If you have a satellite capable of IP, you can still call it a bent pip= e as long as it downlinks traffic that has come in on the uplink=2E You cou= ld even run an IP-based tunnel between dishy and gateway that makes it appe= ar like a single link for the next network layer up the stack=2E And do the= same for lasers=2E There'd be a number of advantages in this=2E > >and bent pipe for normal operations doesn't mean that you can't watch for= an anycast address to serve locally=2E > >>>>>> Practically speaking, we know from various sources that each Starli= nk satellite provides - ballpark - a couple of dozen Gb/s in capacity, and = that active users on a "busy" satellite see a couple of dozen Mb/s of that= =2E "Busy" means most active users, and so we can conclude that the number = of users per satellite who use any site is at most around 1000=2E The subse= t of users navigating to new sites among them is probably in the low 100's = at best=2E If we're excluding new sites that aren't dynamic, we're probably= down to a couple of dozen new static sites being queried per satellite pas= s=2E How many of these queries will be duplicates? Not a lot=2E If we're in= cluding sites that are dynamic, we're still not getting a huge probability = of cache entry re-use=2E >>>>>=20 >>>>> I think that each user is typically going to use a lot less than the= 'couple dozen MB' that is the limits that we see, so the number of users i= n a cell would be much higher=2E >>>> Yes, but these users aren't "active" in the sense that they will be f= iring off DNS queries during the pass=2E=2E=2E >>>=20 >>> even users who are using the connection aren't going to be using dozen= s of MB of bandwidth=2E >> Yes - but that should reflect as a lower level of DNS usage in most cas= es, shouldn't it? > >not necessarily, if they are browsing pages that are made of small pieces= , they can generate lots of connections and lots of DNS lookups, but not co= nsume a lot of bandwidth=2E You don't get to the dozens of MB range without= some bulk download traffic in there=2E > >David Lang >_______________________________________________ >Starlink mailing list >Starlink@lists=2Ebufferbloat=2Enet >https://lists=2Ebufferbloat=2Enet/listinfo/starlink --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------W2GCSVQ8EPHBHO3WOKSGYOYDSEWJ4P Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Interesting discussion=2E

One other thing t= o keep in mind, some jurisdictions like the EU (in a broader sense, members= typically crate their own EU compatible laws) legally mandated DNS blockin= g of specific addresses is a thing, and our LEO DNS operator likely would n= ed to honor these when over such regions making the whole thing even more c= omplicated and likely less attractive=2E=2E=2E

On 17 April 2023 07:01:41 CEST, David Lang via Starlink <starlink@= lists=2Ebufferbloat=2Enet> wrote:
On Mon, 17 Apr 2023, Ulrich Speidel wro=
te:

On 17/04/2023 2=
:34 pm, David Lang wrote:
On Mon, 17 Apr 2023, Ulrich Speidel wrote:

On 17/04/2023 1:04 pm, David Lang wrote:
I think it is going to be fair=
ly common, but the beauty of the idea is that you don't have to risk much t=
o try it=2E Long lived DNS answers (and especially root servers and TLD ser=
vers) can trivially be mirrored to the satellites, and you can experiment w=
ith caching to see what sort of hit rate you get=2E Even if you don't cache=
 a lot of the CDN type traffic, it should still be a win to have the longer=
 term stuff there=2E

Yes - but root servers and TLD ser=
vers also get cached a long time at the clients=2E If each of your clients =
needs a root server and a few TLD lookups a day, it's not a huge gain in te=
rms of performance=2E

It is however a significant step up in terms o=
f complexity=2E E=2Eg=2E, your satellite-based DNS would have to point you =
at the TLD server that is topologically closest to your Starlink gateway, o=
r risk a potentially much longer RTT for the lookup=2E So you'd need to mai=
ntain a list of TLD instances on your satellite-based DNS and return the on=
e that corresponds to what your gateway-based DNS would get=2E Sure possibl=
e but more complex than a bog standard DNS server in a fixed network=2E
=


really? I don't think the root and TLD servers do any geol=
ocation, I think they have fixed answers and rely on anycast addresses to f=
ind the closest one=2E Adding those anycast addresses to the satellites wou=
ld be transpoarent to all users (assuming the satellites are operating at t=
he IP layer, the old bent-pipe approach did not, but once you have routing =
in space via the laser links=2E=2E=2E)

So what you're s=
uggesting would be a generic anycast-based set of DNS records to be kept on=
 all satellites?

Hm=2E My terrestrial RTT to the closest 8=2E8=2E8=
=2E8 and 8=2E8=2E4=2E4 anycast DNS servers is about 28 ms, indicating that =
they're over in Australia=2E No big surprise here, but that RTT isn't all t=
oo different from what I'd expect from a Starlink connection=2E That compar=
es to < 1 ms to my local resolver=2E

Would an anycast-based gener=
ic DNS give us better RTT than a gateway-based DNS with full ability to cac=
he local information?

are you going to replicate the ro= ot server data to your gateway? what's a fairly trivial amount of data for = a server (including one in space) can be a significant amount of data to st= ore on an AP/gateway=2E If you have your gateway caching it, you probably w= on't hit the space based servers in any case=2E

in part it would dep= end on how much the gateway gets turned off=2E (some people do it for secur= ity, people who are mobile power things down to move)

Even with the laser links, it's worth re= peating that most of Starlink's operation is still bent pipe, and likely to= continue to be so in future=2E There is little evidence that the lasers ar= e currently being used for anything but remote location access=2E

Th= at said, bent pipe isn't the same as bent pipe=2E Analog telecom GEO sats u= sed to do physical layer bent pipe with the satellite incapable of IP=2E If= you have a satellite capable of IP, you can still call it a bent pipe as l= ong as it downlinks traffic that has come in on the uplink=2E You could eve= n run an IP-based tunnel between dishy and gateway that makes it appear lik= e a single link for the next network layer up the stack=2E And do the same = for lasers=2E There'd be a number of advantages in this=2E
=
and bent pipe for normal operations doesn't mean that you can't watch f= or an anycast address to serve locally=2E

Practi= cally speaking, we know from various sources that each Starlink satellite p= rovides - ballpark - a couple of dozen Gb/s in capacity, and that active us= ers on a "busy" satellite see a couple of dozen Mb/s of that=2E "Busy" mean= s most active users, and so we can conclude that the number of users per sa= tellite who use any site is at most around 1000=2E The subset of users navi= gating to new sites among them is probably in the low 100's at best=2E If w= e're excluding new sites that aren't dynamic, we're probably down to a coup= le of dozen new static sites being queried per satellite pass=2E How many o= f these queries will be duplicates? Not a lot=2E If we're including sites t= hat are dynamic, we're still not getting a huge probability of cache entry = re-use=2E

I think that each user is typically going to = use a lot less than the 'couple dozen MB' that is the limits that we see, s= o the number of users in a cell would be much higher=2E
Yes= , but these users aren't "active" in the sense that they will be firing off= DNS queries during the pass=2E=2E=2E

even users who ar= e using the connection aren't going to be using dozens of MB of bandwidth= =2E
Yes - but that should reflect as a lower level of DNS u= sage in most cases, shouldn't it?

not necessarily, if t= hey are browsing pages that are made of small pieces, they can generate lot= s of connections and lots of DNS lookups, but not consume a lot of bandwidt= h=2E You don't get to the dozens of MB range without some bulk download tra= ffic in there=2E

David Lang
Starlink mailing list
Starlink@lis= ts=2Ebufferbloat=2Enet
https://lists=2Ebufferbloat=2Enet/listinfo/starlink
<= /pre>
--
Sent from my= Android device with K-9 Mail=2E Please excuse my brevity=2E
------W2GCSVQ8EPHBHO3WOKSGYOYDSEWJ4P--