Moon base internet functionality

It's 2020 and I've decided the perfect location for my next villainous lair is on the Moon (Earth has too many pesky heroes after all). Fortunately, construction and transit shouldn't be too difficult, I have teleportation technology, however it's not instantaneous but rather lightspeed.

This brings up an interesting problem, namely internet: my minions and I need high bandwidth (for netflix and evil plotting) but since there's no way to get around lightspeed, the base is already looking at ~2 second ping times. This raises the question:

How much of the internet becomes inaccessible with Lunar ping times?

I'm assuming that highly interactive websites and web services would have problems...

I'll claim expertise on this issue since I live in the Arctic in a remote community where all telecommunication is via satellite and, based on the quick test I just ran, I have about a 750 millisecond ping. And that's vastly improved over what I had to deal with just a few years ago.

It's entirely not an issue so long as, as some people have mentioned, people don't try to do things that require low latency like online gaming. Otherwise, it's not not really noticeable. You and the minions are going to notice things like videocalls are going to have a multisecond lag, but that's merely a case of getting used to it. Once you start a download/upload, it's going to progress based purely on the bandwidth available, not the latency.

Also of note for things like Netflix, there are mines up my way where bandwidth is limited due to costs, but the mine still offers services like Netflix. What they do is a single mass download of programming every so often to an on-site servers and the workers who have Netflix accounts, instead of connecting to the Internet, are directed to the selection on the local server. This model is used quite often in remote locations, so you and the minions might not even have any delay at all.

• The lag time means your and your minions will communicate by efficient email instead of wasting time in video calls, thus giving you a significant advantage over the superheros who insist on "face time" :-) And last I checked, friends who live in a place that has both high ping time and low bandwidth got their Netflix fixes supplied by snail mail. – jamesqf Oct 18 '20 at 16:19
• Some error correction relies on the recipient sending back information to the server. This could become problematic if the delays are extreme, so higher redundancy transmission might take hold and thus a reduced practical bandwidth. – BMF Oct 18 '20 at 21:18
• TCP slow-start forms a partial exception. The higher your latency, the longer it takes for a download to "get up to speed" and use all of the available bandwidth, because it takes a number of round-trips to scale up the window appropriately. The inconvenience caused by a dropped packet also increases in proportion to the latency. – hobbs Oct 19 '20 at 2:53
• He has teleportation technology. Just teleport external hard drive up to the base from time to time. Or, for the best efficiency, teleport a box of SD cards! what-if.xkcd.com/31 – jo1storm Oct 19 '20 at 7:14
• I gather Netflix does the same thing everywhere, not just remote locations - large ISPs will have a cache within their data centres with the popular / new shows. This reduces the load on the ISP and on Netflix, and increases responsiveness for the user, so it’s a win win win. – Tim Oct 19 '20 at 7:48

Without modifications you would have a multiple of these 2 seconds, since you need to make a DNS request and a three-way handshake to make TCP connections.

But even with 10 seconds the delay isn't that big. User experience would suck, and competitive online game would be out of the question, but from a technical point of view latency should not be a big problem and anyone who has lived through the 90ies might remember :)

Throughput might become a problem though. There already is places that rely on satellites for internet (e.g. Micronesian islands) and loading a normal website can take minutes, however even with a pageload time of 2 minutes, a lot of websites are still usable, unless you are using one of these pages that kick you out after 10 minutes, if you haven't finished your booking, but those suck on earth too.

To improve the situation you can have local caches, CDNs, nameserver and tunnels that keep the TCP connections alive to avoid unnecessary roundtrip times and avoid Software as a service:

• use usenet instead of stackexchange
• "competitive online game would be out of the question" - turn-based should still be fine, unless there are tight turn limits that don't account for latency. – John Dvorak Oct 18 '20 at 13:57
• Yes, I had Starcraf and Counter Strike in mind, or whatever kids are playing today. Chess should still be fine :) – Helena Oct 18 '20 at 14:05
• When humans are multiplanetary, I think it's very likely we'll see a huge resurgence of "play by mail" style turn-based games. – Thane Brimhall Oct 18 '20 at 16:16
• Maybe Elon Musk really is into play by mail style games. – Helena Oct 18 '20 at 17:29
• The OP says they have a link capable of high bandwidth. Keeping it filled would be a huge latency x bandwidth product of data in flight (huge TCP window size) for downloads or streaming video; the sending side might cap the window size lower than you'd like? IDK, I haven't kept up with TCP tuning details. But you're right that stuff like page-load times would be limited by latency of round trips for redirects and resources like scripts loaded by a page. Certainly you'd want to run your own DNS cache and HTTP proxy cache, although HTTPS makes that harder. – Peter Cordes Oct 18 '20 at 22:01

Web browsing will be slow but work out of the box

Most modern web content authoring implicitly assumes latency is much lower. So a lot of code is written that does some computation locally, then based on the result, contacts a server and requests additional info.

Google shows different results depending on who you're logged in as. Many site designs now use endless-scrolling, where instead of a "click here for the next page" link, when you get down to the bottom of the page, it "seamlessly" loads the next page of (articles / search results / whatever). Or at least, it's supposed to be seamless. But if you've ever been trying to use one of these sites when there's network trouble, you've noticed it doesn't work very well.

If the lunar population gets big enough, major browsers eventually create & implement standards to configure browsers to operate in "interplanetary latency" mode, which will be a different flow redesigned to request things in as few round trips as possible, or to instead of requesting new data when it's needed, predictively try to load it before it's needed, to make it appear more seamless.

Caching layers will also be a big help, but won't necessarily be a panacea

Voice chat probably becomes push-to-talk

If two people start talking over each other, it will take several seconds before it's even possible for the participants to realize. That will quickly become maddening.

So redesign the way chat works so that's just not allowed to happen in the first place. Current voice chat systems allow anyone connected to talk whenever they want. Nobody said it has to work that way.

Only one person will be talking at a time. When they're done talking, they release the 'talk' button. They won't hear a reply until 2x the light lag after they stop talking, obviously. When the recipient gets the message, their computer will automatically know "message over, you can talk now".

Eventually other features would get added. Such as a "want to talk" button, in case someone won't cede the floor and keeps going on about catching the ferry to Shelbyville, or a way to forcibly interrupt anyway. Or the system will know how long the lag is, and if it detects silence for that many seconds, it will assume they're done talking.

Video chat

Once you have the voice chat functionality, video chat is pretty easy. Just sync the video to the voice and when someone's not talking, fade them to a blank screen.

TL;DR

It will kind of sorta work out of the box, but after work is done to make it more natural, sending traffic across a lunar link is only slightly less convenient than sending it terrestrially (except for obviously impossible things like gaming or telesurgery).

• push-to-talk doesn't solve the collision problem if both people think of something to say simultaneously. Unless you can only even start talking after one "way" of latency to make sure the other party didn't send a message. But then the cure is worse than the disease for a 2-person chat, vs. just learning to say "over" when done, and learning to structure what you say into discrete sentences / ideas that clearly have an end. – Peter Cordes Oct 18 '20 at 21:49
• I'm envisioning it more as guiderails - if you really want to un-mute yourself and start talking over somebody, it probably won't prevent you (in 1:1 communication anyway), but rather the defaults will be an automated flow that mostly does what the polite and orderly thing to do would be anyway, only done perfectly. Think web conferencing software: it has tons of features to let meeting organizers control who can do what. This will be just a very different use case and feature set. – Ton Day Oct 19 '20 at 10:00
• I think you're missing my point. There is no zero-latency path available to coordinate who's allowed to talk. If you on the moon press your push-to-talk button while the start of someone else's press-and-talk is in flight, you'll collide. The system could use timestamps to decide who started first and mute you if the incoming message started first (so other participants will see at most ~2 seconds of overlap). That could be usable for humans, unlike for 10base2 ethernet over coax cables where 2 stations that start transmitting without seeing each other's packets ruin the whole packet. – Peter Cordes Oct 19 '20 at 10:17
• I guess I wasn't clear. The point is to solve that. Whoever initiates a call talks first & when the receiving party answers they're already automuted. They don't get permission to talk until the other side stops (the software constantly transmits a 'still talking yes/no' flag so it just knows this). It alternates by default; you can't take the floor unless the other party has a go. If you want to take the floor on a dead channel, you push "want to talk" and wait long enough the light lag on all ends has elapsed. (Yes, it's easy enough to autodetect how long this is.) – Ton Day Oct 19 '20 at 22:06
• That handles 1:1 calls. Conference (multiway) calls require more complex permission negotiation. However this is a well known & already solved computer science problem: en.wikipedia.org/wiki/Semaphore_(programming) and the TL;DR is synchronizing on a shared resource - like this - is solved. I won't call the solutions "straightforward" (they, uh, aren't), but they are well known & understood. I'll skip the nitty-gritty cause, uh, I get paid to do that :) and it's getting too far into the weeds for the OP's needs. The important thing is we already know how to solve this problem. – Ton Day Oct 19 '20 at 22:14

Since you have the funds to build a moonbase, you should be able to cache a vast majority of the Internet for comparatively little cost.

Google says the Internet is about 1.2 million Terrabytes, but you can get a 2TB hard drive for about 70 USD. So you could store a local copy of the entire Internet for about 84 million USD. Considering NASA was throwing billions of USD around to get to the moon, your cost saving from teleportation should make that pocket change.

Thus, you can have a bunch if Google-spider style crawlers making copies of the Internet and transferring it over to your moon base, and it would be simple to have them prioritise your favourite websites being up to date.

The only challenge then would be interactivity. But with your copy of the entire Internet, you will be able to send your Earth-side servers your requests and have a reasonable expectation of the response you will receive whilst it handles the ms delay handshaking that your two second lag can't afford.

Of course, if 84 million stretches your budget, I'm sure you can cut out the stuff you don't care about so much and just have a little delay as your Earth-side servers send you copies of information.

Like others have mentioned, you won't be able to play any online games that require quick reflexes, but having played online games, I can appreciate why you want to get away from them.

• You can even play online games requiring quick reflexes as long as you put a server for that game on the Moon. Basically there would be two Internets with systemic interchanged information. – Mary Oct 17 '20 at 15:41
• The majority of interesting content is not static. You can't cache all of it because you simply don't know about all if at any given time (think: people are adding new Instagram, LinkedIn, FB accounts, listing eBay items, etc. all the time). – Lawnmower Man Oct 18 '20 at 4:44
• @lawnmowerman But we're talking about the useful part of the internet ;) – Mr47 Oct 18 '20 at 8:56
• Old tech me excludes webpages from that useful part. For info go to gopher :) – Hennes Oct 18 '20 at 9:47
• @LawnmowerMan If the OP cares about being up-to-date on Instagram, then they can just set that website to have its own dedicated web-crawler. It wouldn't be hard to have an Earth-Side system that just refreshes your newsfeed and pushes up the changes either – Kyyshak Oct 18 '20 at 10:56

Invite Big Tech

Instead of solving the problem by yourself, which is basically impossible for many jibbly bits of the internet that you and your minions care about, do what Big Tech does, and push the hard work onto someone else. Tell them you are building an open community on the moon, and naturally, your moonie citizens will want internet access. Wave around some big [villainously stolen] bucks like the moon is the hottest new market for them to expand into, and watch them trip over themselves building satellite relays and datacenters to extend their services to the moon.

You see, although some folks have suggested that you just crawl and cache the web yourself, this will only work for mostly-static content, like blogs, news, videos, and Wikipedia. Booooorrrr-ring!!! Way to lose a whole cohort of minions who are not impressed by the intertubes perks of your little criminal enterprise.

I mean, Google takes 4 days to 6 months to crawl the internet (obviously, it looks in some corners more frequently than others). Do you really want to wait 4 days for a tweet to show up? Way to totally miss the party! No, you want your portion of the internet to work like everyone else's. Don't do the caching yourself...make Big Tech do it. Once they are convinced that there is a serviceable market on the moon, comprised of big spenders, then they will invest the infrastructure to extend their services to the moon, with adequately low latency. There will be caches involved, for sure, but they will be owned and operated by Big Tech, and those eggheads will be responsible for refreshing them efficiently and often. As far as Big Tech is concerned, the moon is just another AWS region with really bad latency.

Of course, this means that real-time interactive services will work best with other moonies, and will work awkwardly with earthlings (video conferencing, action games, etc.). Also, I'm assuming you build your evil lair on the dark side of the moon, and contrive some reason for the new innocent moonies to avoid that. After all, you need them to "pay for" your internet service! But at the end of the day, anything that doesn't require a ping time of less than 2000 ms will eventually be made to work, and anything that does will get suitably adapted for the high latency.

• +1 AWS Moon Region #1 - bad latency to/from Earth, excellent latency locally. – OnoSendai Oct 19 '20 at 18:13
• NASA has just funded Nokia America to the tune of 14 million USD to build a demonstration platform for a proposed LTE/4G space communication system designed to support lunar surface exploration. – Mon Oct 20 '20 at 0:27
• @Mon lol I saw that story too...truth is stranger than fiction! Hard to keep up on the writing front these days... – Lawnmower Man Oct 20 '20 at 2:25

A lot of websites would work just fine. Its just that they would be really slow.

Having myself written a lot of networking code for custom systems, I know a little about this problem.

You are correct that TCP (which is the backbone of most internet communications) would have to wait a minimum of 2s for the acknowledge on each data segment. This would slow down things quite a bit.

In fact any protocol that sends small packets of data and then requires an acknowledge will suffer.

In general there are two solutions. Those solutions won't allow you to eliminate latency in cases where data does need to make a round trip. But what you can do is speed up data rates in cases where it doesn't.

NASA already solved this problem for its Deep Space Network System. Given that the round trip to mars can be over 40 minutes its likely that data sent back from the mars rover probably isn't sent using normal TCP.

https://en.wikipedia.org/wiki/NASA_Deep_Space_Network

There are two solutions for increasing transfer rates in the presence of high latency. Both require that your evil villain has someone who can write their own transmission protocol or steal some code from NASA.

1. Create a new data transmission protocol that sends much more data between each acknowledge.

a. If you send 0.1 second worth of data and wait 2 seconds for an ACK then you are spending 95% of your time waiting.

b. If you send 18 seconds worth of data and wait 2 seconds for an ACK then you are only spending 10% of your time waiting.

2. Make a protocol that includes lots of error correction so you don't need an acknowledge. You can't make any communications 100% error free buy you can make it very close.

a. For example, just sending each packet multiple times on different bands. The probability of all packets failing can be very small. Sure it uses more bandwidth, but you data rate will actually be much higher than if you were stuck waiting for TCP ACKs.

b. Include error correcting codes in the data that allow you to recover lost bits. In general this will be more efficient than simple packet duplication, but more complex to implement.

Since the internet doesn't speak your custom protocols, you will need to have a ground station (or stations) somewhere that receive your communications and act as a proxy. The proxy does all the talking to the internet using normal protocols, and then uses your special protocol to transfer data between space and ground.

For example, you want to watch Netflix. Your computer sends a request to the ground station to establish a session with a local Netflix server. Netflix sends the data to the proxy. The proxy then streams the show to you using your new protocol. Problem solved. Some stuff like browsing menus or starting a movie might be slower, but once it gets going you will be able to stream at close to the normal rate.

As per my answer to How can invading aliens access the Internet to find out all about us?, the threshold for proper communication in TCP/IP should be a handful of minutes (3 for many servers). UDP on the other hand doesn't care by design, though some applications(i.e.: Skype, Zoom) are programmed to care and may drop connections that have high latency.

Your latency will be within less than a handful of seconds, a whole order of magnitude less time than the latency to Mars (at closest). You will be able to browse sites like the Stack Exchange just fine. You will also be able to use most streaming sites, so your porn educational needs are covered. Some applications like FaceTime and online gaming won't accept the high latency, though.

By the way, since you can teleport to the Moon, have you considered running a cat 5 cable from the Moon to your router on Earth through a portal? I'd totally crimp both ends for you for free. You'd still have lightspeed limitations, but not having to go through satellites would save you precious time and reduce latency.

• prettty sure cat 5 has a distance limit slightly under that distance... I wonder if you could go for a really long fibre optic bundle instead. – Journeyman Geek Oct 18 '20 at 11:44
• @journeymangeek isn't the point of a portal to shorten distances? The cable might be 10m long and work. – The Square-Cube Law Oct 18 '20 at 13:36
• @TheSquare-CubeLaw teleportation still obeys the light speed limit. The only thing it saves you is the necessity to haul all of the fuel to low Earth orbit, accelerate a lot and decelerate a lot. I suppose it's not a physical portal but rather a startrequesque transcoding to particles that ignore gravity and catching them on the moon... or perhaps a system of hyperspace elevators. – John Dvorak Oct 18 '20 at 14:04
• @TheSquare-CubeLaw a wormholish thing would allow you to bypass the light speed limit, so that's not it. – John Dvorak Oct 18 '20 at 15:12
• @TheSquare-CubeLaw the follow-up question would be how to design a robot / self-moving rack that would autonomously load a bunch of microSDs from one server, hitch the hyperchunnel ride, dump the data into another machine, hitch a ride back and repeat. Presumably the rack could stay within a designated cab the whole time, but it would still need to reconnect repeatedly... or maybe free-space optics would be fast enough? Scratch that. Wifi. Wifi will do. Not as fun though – John Dvorak Oct 18 '20 at 15:18

Two-second ping times are not an issue outside of interactive applications which require reactions in real-time, such as telerobotics or most online games.

TCP, as a general rule, doesn't care about latency, and RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers", has been successfully implemented with ping times in the 3 000 000-6 000 000 millisecond range (50 - 100 minutes) over a distance of 5 km, albeit with a 55% packet loss rate. More details at wikipedia.

As you move up the network stack to server and application software, most services such as HTTP, IMAP, FTP, etc. tend to be configured with timeouts in the 5-15 minute range. These timeouts would need to be extended if IP over avian carrier were to come into common usage, but should pose no issues for lightspeed earth-to-moon communication links.

• Though TCP won't break with very long ping times. Your throughput will drop due to waiting a long time for ACKs. – user4574 Oct 19 '20 at 3:23

An evil villain, who can manage two-way transport for himself, hordes of yellow minions, and construction of facilities, can surely manage the installation of a sizable data farm.

Your evil villain can further boost his ego by making a local copy of the internet (a giant internet mirror for the moon) that automatically synchronizes with the Earth-based internet. For researching an plotting purposes, your ping times will be no greater than that on Earth, probably much less, due to reduced usage and proximity to the local server. Anything requiring live interaction with dynamic content, such as gaming, chats, forums, etc. will be subject to the expected lag time.

Latency and bandwidth for a one-way link are independent (like a fiber-optic cable, or a giant frickin' laser ... modulated and pointed at a receiver, probably on a relay satellite). A long high-bandwidth link simply has a large "latency x bandwidth product" aka BDP (Bandwidth Delay Product) = amount of data that can be "in flight" over the link. aka a "long fat network".

Using such a link with communication protocols like TCP is very possible; TCP was extended to handle lots of in-flight data in one TCP connection, e.g. a streaming video. (RFC1323 in 1992 introduced TCP Window Scaling. Linux turned that on by default around 2004, Windows a few years later, so desktops should work decently out of the box.) A single TCP connection can in theory have up to about 1GiB of data in flight (each way), if both sides support the max window scale. But each side needs a send/receive buffer that big to handle lost packets that need to be re-sent, so in practice the max window size will be smaller. A 16MiB TCP buffer (the default max in some Windows versions) and a 4 second round-trip time gives you a per-connection ideal bandwidth of 4MiB/s, or about 32 Mbit/s. (With the max possible window size, ~1GiB, a 4 second RTT gives a max per-connection bandwidth of 256 MiB/s, or 2Gbit/s. So in theory with huge send/receive buffers, gigabit ethernet won't be a bottleneck.)

(some background on how TCP works and what the "window" is, as part of implementing a reliable stream over a packet network that can delay, reorder, and drop packets.)

Separate TCP connections over the same lower-level link have zero impact on each other as long as the underlying IP and physical layer can keep up with the total throughput, and each TCP connection has its own "window". Including separate downloads from the same computer to the same server.

Most transfers aren't that long: latency is the major factor

The calculation above is relevant for a huge download that lasts much longer than the 4-second RTT. Ramping up the TCP window size at the start of a big download happens exponentially (TCP fast start), but still takes some time. Unless you're downloading a CD image or whole movie, probably not relevant.

Loading a web page usually involves many small transfers, many to different sites. Or even if they're to the same site, the data from the first URL has to be received before the browser knows what to fetch next. (The HTML refers to a bunch of images, .js, .css, etc.) For these, latency is much more of a factor than actual bandwidth. (Having lots of link bandwidth will stop multiple users from interfering with each other, though.) Other answers go into more detail about this, it's certainly viable.

You'll definitely want a caching DNS proxy, and a web cache. Running a web cache is harder than it used to be, now that everything uses HTTPS, but it's fine if users configure their browsers to use it. (Doing it transparently requires basically hijacking and MITMing every HTTPS connection; apparently some ISPs and/or companies do this by distributing an SSL root certificate that computers on the network should use, making this possible. You're evil so that might be a good solution...)

Caching static content like images and scripts can definitely help for the average load times of commonly used pages.

Achieving high bandwidth for the physical layer

With enough power (to give high signal:noise ratio), bandwidth is in theory easy. A point-to-point laser link with a relay satellite in geostationary earth orbit (or satellites in LEO), can use a large range of optical frequencies. (wikipedia: Shannon limit on channel capacity)

Note that "bandwidth" in that article is the actual range of frequencies, like how a WiFi channel is only 20, 40, or 80MHz wide, and is part of calculating how much information you can send over it at a given SnR. What we call "bandwidth" in terms of bytes/second is the channel capacity in info-theory terminology.

A laser between the moon and a near-earth satellite might be better than all the way to the ground: no atmospheric distortion. The last hop down to Earth can use microwave comm links with normal satellite dishes on the ground, like normal comms satellites. The laser modulation and probably also receive could be done with gear designed for long-distance fiber optic links, again commercially available.

If you're mostly watching movies and stuff on the moon, the higher-bandwidth direction will be earth->moon, and the sending laser for that would have to be powered by the satellite. Transmit power is important. Perhaps a RTG (radio-isotope thermal generator), because you're evil, to give a nice large power budget, more than solar panels. The receive side on the moon can use an optical telescope to catch more light from the laser beam that will spread some over that long trip, boosting the signal:noise ratio.

OTOH, ground stations on both ends could use large microwave antennas and high transmit powers to cover the distance.

Multiple ground stations (or satellites) could give redundancy, as well as distributing bandwidth. And/or route traffic to a place on earth near where the packet should go, to avoid some of that last maybe 100ms of latency going half way around the earth. Of course ground stations would go below the horizon so you'd need multiple anyway.

You definitely want this link to be low-error: lost packets will lead to TCP retransmits once the loss is detected, which only get detected on the moon side and thus take a round trip. So forward error correction is important, even at the cost of some throughput to push the error rate down lower than you might for a terrestrial link. (Or IDK, maybe comms links normally use plenty anyway.)

Video streaming generally won't work

Most video streaming systems split videos into 2-10 second segments, usually 6, and the client is responsible for downloading each segment in order using HTTPS (See HLS and DASH). Which means:

• A TCP handshake (3 round trips, i.e. 6 seconds, could maybe send acknowledgements before receiving the packets to short-circuit the wait)
• A TLS handshake* (2 round trips, i.e. 4 seconds, cannot be short-circuited)
• Several TCP packets for HTTP headers (at least 1 round trip)
• Several more packets for responses (hundreds of round trips?)

It will take at least 10s to download any segment of video, which isn't going to cut it here. *Note that it may be possible to reuse and pipeline connections, which may be enough to allow this to work, but I wouldn't count on it, as this depends on implementation details on both the client and server.

This limitation, however, does not apply to constant bitrate video like you might get on Satellite/Cable TV. Unfortunately, TV satellites are geosynchronous and pointing at Earth, so you can't get TV. And no, IP TV won't let you get around that because it's encoded to adaptive bitrates (with the segments) in real time. That is, unless you butter up / bribe some executive to get access to the source multicast channels sent by content providers.

Torrenting is probably a better option for your video entertainment needs.

Other than that, it will just be slow

All other HTTPS content suffers the same delays as video, but it's less of an issue. Sites will take at least 10 seconds to load, and most will take far longer because the browser often doesn't know what additional content it needs to load until it receives and parses the html, which done poorly, can lead to a cascade of sequential network requests. HTTP2 server push can alleviate this somewhat, but expect to be waiting 30-60 seconds on most sites. Single Page Applications will be near-unusable in some cases due to sloppy and excessive network use. Timeouts will be relatively uncommon though, so most webpages will work eventually.

For any static files over a couple megabytes, you'll probably want to torrent. The unreliability of connections coupled with TCP's slowness for this kind of connection is likely to cause multiple-hour-long downloads for anything bigger than a few megabytes. Torrenting sidesteps this by allowing files to be downloaded out of order and pieced together.

Online Gaming

It should go without saying that 2000ms of ping is going to be unplayable for most games. On the bright side, turn-based strategy games will be unaffected, so I hope you like Chess.

Note on torrenting

Torrenting is not illegal in itself. It's only illegal if you use it to obtain media you are not licensed to have. Several legitimate products use torrenting to save on bandwidth.

Torrenting won't be as dramatically affected by Moon latency because it uses UDP instead of TCP and has error correction models that are much friendlier to packet loss/corruption.

Current internet infrastructure is not nice to moon colonists.

Stick to LAN and torrents.

• Does each 10-second segment really open a new TCP / HTTPS connection? I thought browsers would pipeline additional requests inside the same existing connection. Once you have a connection open and streaming data, it's just a matter of the TCP window being large enough, and pipelining your requests using HTTP pipelining inside that one connection. – Peter Cordes Oct 20 '20 at 1:57
• But even if you did need a fresh connection for each chunk, you can pipeline things by starting a new TCP connection every 10 seconds, whether you've finished receiving the data from the older one or not. It's just a matter of how deeply you need to pipeline (how many open connections in flight). Note that TCP by design pipelines the ACKs, so the round-trip latency doesn't add up per TCP segment. (See my answer re: large TCP window sizes) – Peter Cordes Oct 20 '20 at 1:58
• Your points about additional round-trips for HTTPS negotiation are a real problem for web browsing, even if not for streaming video. But note that sending additional requests over an existing open HTTPS connection only needs one RTT. Even without HTTP/2, en.wikipedia.org/wiki/HTTP_pipelining is a thing. (Although Wiki reports it's not enabled by default in most browsers, but you could enable it. Especially in a proxy cache.) Or at worse, open two separate connections to the server in parallel if they don't support HTTP/2, so you can request 2 images or w/e in parallel. – Peter Cordes Oct 20 '20 at 2:04
• Keep-Alive headers and websockets can help to avoid additional handshakes, but not all servers support those. There will still be several serial requests for images, css, and javascript after loading any html, meaning at least one round trip. Only pure html is going to load in one pass. And then there's the possibility that more stuff will be loaded by javascript- notably REST calls. REST APIs often are going to involve more serial network use. Unless the website is designed to be friendly to moon people, you aren't going to have a good experience. – Beefster Oct 20 '20 at 15:54
• Agreed interactive browsing is probably going to suck, just possibly slightly less bad than you described. – Peter Cordes Oct 20 '20 at 16:00

How much of the internet becomes inaccessible with Lunar ping times?

Technically there is nothing that will be inaccessible, just a bunch that is going to be frustratingly slow. Slower than most people think because of how the internet works, but not completely broken.

To reduce the latency impact you'll need a few things...

1. Orbit To Ground communication protocol

TCP is not your friend in high latency connections. Session initiation takes some back-and-forth of SYN/SYN-ACK/ACK packets to establish the link. The moon is ~1.3 light seconds away, so minimum 3.9 seconds to initiate a TCP session from the moon to the ground station... and that's before you can even start sending packets to make your HTTP request. And any time you drop a packet the whole connection pauses until the data is retransmitted, which means your send buffering is going to be freaking huge.

So what you need here is a high-redundancy connectionless protocol. Every bit of data you send goes out multiple times over the one-way delay period, interleaved with subsequent data and tagged with sequence numbers so it can be reassembled at the far end. Adjust the retransmission period depending on the observed packet loss - the less you have to repeat yourself the higher your effective bandwidth.

2. Proxy everything

TCP traffic via SOCKS proxy is an old technique and still alive and well. You don't have to care what's happening in between the lunar and ground proxies, just like you don't need to know how packets travel around the TOR network.

3. Cache aggressively

Anything that can be cached should be. DNS, HTTP(S), etc. API traffic is probably not going to be amenable to caching, but some of it can be caputured. Make sure that your ground proxy can handle predictive caching so that you don't have to wait quite so long for images to load and so on.

4. Get used to waiting...

At the end of the day you're going to run up against the latency problem no matter how clever you are about optimizing the link. Some things are just going to take more time to happen, that's all.

5. ...or bypass it!

But wait! You don't have to sit on the moon and suffer, because you can step through your teleporter to one of several secure bunkers on Earth whenever it's absolutely critical to avoid the latency issue! Need to monitor your henchmen while they carry out your nefarious plot? Step into the local bunker and watch from there with millisecond latency. Need to gloat over the pathetic do-gooders? Again, do it from the comfort of your local bunker. Need to unwind with a little online gaming? Head to a bunker close to the game's servers and show the silly gamers how a true evil mastermind cleans up at <insert your favorite online game here>.

Boxes. Thinking outside of them is what Evil Geniuses (Genii?) do best.

I think @Helena's answer above is wonderful, it's what I would say (20 year IT industry veteran, mainly as a Network Engineer, and a fair chunk was supporting a long-distance microwave WAN link between two cities)

I'd like to add two bits to the conversation though, first, this:

https://www.bbc.co.uk/newsround/54611342

...so the answer will be IRL at some point sooner rather than later :)

Second: My experience with the long-distance WAN (approx 80-100 km, 50-60 miles) was that it was mostly reliable, however we would lose connectivity across the links, strangely, over hot, still days. Our links crossed a large body of water, a bay between the two cities and what was happening on those hot still days (38-40+ degrees Celcius, over 100 Fahrenheit) was that the beam suffered attenuation and dropouts due, according to our microwave vendors, the heat in the atmosphere, coupled with humidity, seemed to bend the signal just slightly the wrong way and enough that the signal dropped out. It only happened on super hot days, and was an annoying blip on what was at the time a backup link, but enough to be noteworthy. An interesting wrinkle for you to consider anyway :)

This site explains some of the difficulties, more focused on rain and shorter links, but as they explain, countered with good engineering (big dishes for example mean a bigger target for the beam to hit) many of these problems could be overcome: