# Background

It is the near future. After a major world war and limited nuclear exchange, the nations of Earth have consolidated into a few blocs. The threat of further war and the cumulative damage to the planet spur enormous private investment in colonization of space. Floating colonies surround Earth and near-Earth orbits of Sol. The terraforming of Mars has begun. A great demand for resources off-Earth has spread asteroid mining operations throughout the solar system.

A great number of factions have developed in space. No one faction has enough resources to build a communications system spanning the entire inner solar system, especially considering that deployment cost of communications nodes is high (rockets are expensive). The competing factions settle on developing a collaborative communications system modeled on the Internet, where no one faction can be dominant.

# Problem

The Internet Protocol Suite (with Link, Internet, and Transport layers) works well on Earth, where static computers are connected to each other by cables. The cables allow near-instantaneous communication, and the hardwired connections are rarely changed. On an interplanetary scale, two major problems arrive.

• Sparse connections: Cables on earth are cheap, but satellite dishes that work over AU distances cost a lot of money, so there are a limited number of connections each node can have. Also, connections can be blocked, based on position relative to planets and the sun. Two nodes may be unable to communicate for hours or days at a time. Importantly, much of the disruption is scheduled, due to easily predicted rotation and orbital characteristics. A good protocol suite will have a built in ability to optimize the physical transfer path from node to node to ensure data gets to where it is going as quickly as possible, and so that two way communications are not interrupted needlessly.

• Latency - Message travel time from one side of the asteroid belt to the other take about 45 minutes. From Earth to mars at closest approach is about 3 minutes. This is a significant when it comes to a TCP/IP or SSL handshake. Protocols should minimize the need for two way communications without sacrificing security. Also, if packets in the same TCP session took two different routes from point A to point B; on Earth this is negligible time difference, but in space they could arrive minutes, or even hours, apart.

# Statement of Work

What is the smallest set of changes you can make to the TCP/IP protocol suite to optimize its performance over interplanetary networks?

The goal is to optimize reliability, throughput, and to minimize unnecessary latency.

# Notes

• Currently, humanity is limited to the inner solar system (out to the Asteroid Belt). However, the developed protocol should be extensible at least to the Kuiper Belt, with latency times of up to 10 hours.
• This question is focused on the Data Link, IP, and Transport layers; assume the physical layer works just fine.
• Here is a report on Space Communications Protocols, though this is for near-Earth space. Here is a discussion of some problems with interplanetary communications.
• I just want to point out that the speed of light already causes latency issues here on Earth. Given the best possible connection, US-to-Australia communication can't do better than about 150ms ping, because that's how long light takes to go ~26,000 miles. This is painfully slow for some applications, like FPS videogames or livestreaming. – Ryan_L Sep 10 '18 at 2:17
• The last sentence of your question has much better information than we could ever propose. – RonJohn Sep 10 '18 at 2:23
• (1) Computer Science Stack Exchange is at cs.stackexchange.com. (2) This is an active area of research; start with the Wikipedia article on Interplanetary Internet and follow the links. (3) The Consultative Committee for Space Data Systems (CCSDS), "composed of the major space agencies of the world" (Wikipedia), is co-ordinating the effort. – AlexP Sep 10 '18 at 2:24
• Possible duplicate: Information Exchange In Space (Full disclosure: The accepted answer is my own.) – user Sep 10 '18 at 10:57
• Possible duplicate of Deep Space Communication Infrastructure – Schwern Sep 10 '18 at 22:39

The obvious answer to delay-tolerant networking is store-and-forward.

With TCP, when a router receives a packet, it immediately sends it on to the next hop—or, if it can't, rejects it and sends back an error.

With a store-and-forward protocol, when a router receives a packet, it looks up the next time it expects to be able to talk to the next hop (possibly choosing from among multiple possibilities based on how big the packet is, what its QoS tags say, etc.) and stores it until then.

Store-and-forward goes back to SMTP, NNTP, UUCP, and other protocols from before the public internet. Before 1994, if your company wanted to have external email, that usually meant your server connecting to your provider twice/day via UUCP and sending and receiving all the outgoing and incoming messages. But modern DTNs need something more granular than "send everything to one host twice/day". (Also, these protocols are designed for infrequently-connected but low-latency-while-connected networks, so they do a lot more noisy handshaking than your want for often-connected but high-latency.)

Meanwhile, store-and-forward on the level of tiny IP packets isn't all that useful, so you add a way for applications to define bundles of multiple packets. You can then route, and QoS, and congestion-manage, entire bundles (so ideally, when you accidentally send home a 4K video instead of an SD one, it times out on your local router instead of wasting all your bandwidth and half your ISP's before getting dropped). As a side benefit, bundles can be large enough that you can afford security features like identity-based routing, which might also be important for a DTN.

The obvious way to do this all is to define a routing overlay network on top of UDP, much like the way (post-BitTorrent) P2P meshes work as an overlay on top of UDP. (Except that, unlike a typical P2P mesh, you want some intelligence so you don’t just retry the UDP packets with exponential backoff and automatically mesh adjustment, but instead store programmable schedules in your routing table, because a lot of things will be predictable—don’t bounce off that lunar satellite for the next 3 hours because it’s blocked by the moon…)

Last I looked at this was about a decade ago, and the state of the art was the experimental protocol in RFC 5050. There have probably been advances since then, and I may not be remembering everything perfectly.

• There is another RFC designed for super-high latency networks: RFC 2549 (IP over avian carriers) – T.E.D. Sep 10 '18 at 11:09
• @T.E.D. I was going to say the same, but I see you beat me to it. RFC2549 is basically all you need :-) – Tonny Sep 10 '18 at 13:22
• FWIW, RFC 5050 is still the newest version of the Bundle Protocol specified; the new version seven is currently in the process of becoming an RFC. – Jonas Schäfer Sep 10 '18 at 13:40
• @T.E.D.: On a more serious note, some guys actually implemented RFC2549, and the changes and tweaks they had to make to the Linux (I think that's what they were using, may have been one of the BSDs, though) network stack to make it work with the extremely long path delays probably are highly relevant to this question. – Jörg W Mittag Sep 10 '18 at 17:56
• @T.E.D. That would be excellent, unfortunately the carrier in the RFC only propagates in a specific medium not known to be present in interplanetary space in sufficient quantities. – Gnudiff Sep 11 '18 at 5:28

NASA as already put some thought into this and has developed a concept called "DTN" or Delay-Tolerant-Networking. Basically it checks if the connection is possible to the next "hop" or station, then sends the data. If it's not available it stores it in the local memory until the connection goes up again. This can operate together or separately from traditional TCP/IP

In terms of infrastructure, I'm imagining a large-scale solution involving a series of large dishes spaced around the planet so that at least one always has a connection to a given location or planet. These dishes act as bridges to the rest of the solar system, beaming out huge quantities of data to their recipients as the connections become available. By networking them together, they can automatically transfer it from one dish to the next as needed.

• – Pete Kirkham Sep 11 '18 at 14:31

You probably want to switch away from TCP/IP which is packet based to something that is content addressable. TCP/IP is built on the assumption you can signal congestion to the people using the network by dropping packets. If your round trip time is high that becomes a very expensive signaling method.

What you would like to do is telling the network you would like a certain piece of information and download it from the nearest node that has that information. That way you can get your information faster if someone else already used that information earlier. An example of a current implementation of this is IPFS (InterPlanetary File System).

It kind of functions like on gigantic bittorrent swarm in that it downloads the needed information from nearby peers that have the information. This reduces duplicate traffic over congested / expensive links and decreases the amount of time it takes to get the information you need.

What is the smallest set of changes you can make to the TCP/IP protocol suite to optimize its performance over interplanetary networks?

I'm a little surprised that no-one has said this yet, but you would use neither TCP nor UDP. It's not workable. The idea of any level of live connection beyond Earth orbit is not reasonable. Round trip to the Moon is 2.6s. We've got a hard-wired internet connection here that gets quite dodgy in severe weather so I've actually experienced internet speeds where ICMP packets have required over 2s for a round-trip and I can tell you that the internet is practically unusable under those conditions.

The best round-trip you can hope for between either Mars or Mercury 6m24s and 6m, respectively. The next most interesting place to be beyond Mars is Jupiter, and your best round-trip time there is well over an hour (69m47s).

The Disruption/Delay Tolerant Network was mentioned. DTN may be suitable for orbital or possibly even Earth-Lunar live network connections, but beyond that you'd use something else.

Interplanetary networking connections would not be live. In fact, you would not have a persistent connection, much less a direct connection to any planetary internet beyond your own. You would send a packet requesting very specific information, and you would receive your return transmission a few or more minutes later, within the limits of having to share the radio spectrum with everyone else in the Solar system. The transmission would be broken up into "packets", but not packets in the TCP sense -- more like packets in the old Fidonet sense. Rather than re-request data, you would simply repeat your request, specifying only those blocks of data which were lost or garbled; protocols would be designed in such as way as to have predictable framing of the data just so that you could request only the bad data.

Some data would be continuously transmitted, some would be available via transponder, and some would be transmitted on some kind of schedule.

There would be some localized synchronization, though not the entire internet. Wikipedia and other large databases, for example, would synchronize locally. Updates would be requested as of a specified timestamp so that only current sync data would be transmitted.

Communication on the interplanetary network would better resemble the old teletype system than it would the old BBS system.

I'm reminded by @Hobbamok that microwave transmission would be used for the point-to-point connections between settlements, outposts, and Earth. Quite possibly laser would also be used where appropriate. That would negate the problem of having to share bandwidth among the rest of the Solar system.

• FidoNet is a great example. I was thinking UUCP and NNTP, but most of the same reasons FidoNet was better for small but broadly connected operators in the 80s will be true in the interplanetary future. – abarnert Sep 10 '18 at 16:50
• But meanwhile, with some minor changes, your Fido-like protocol can be tunneled over UDP the exact same way Fido itself could. And that means IPv7 UDP serves as a lingua franca for connecting up a diverse collection of lower-level protocols with a diverse collection of application-level protocols (or bundle protocols somewhere in between) without needing to implement the whole Cartesian product. – abarnert Sep 10 '18 at 16:54
• +1 for the first sentence. We would not use TCP (or UDP) but something else. Maybe similay, but not quite the same. – Hennes Sep 11 '18 at 4:15
• Why does EVERYONE stick with radio waves? In a civilisation advanced enough to colonize Planets, what would keep us from using finely calibrated laser-links? Far lower transmission time, far less noise and almost NO energy consumption in comparison – Hobbamok Sep 11 '18 at 9:45
• @Hobbamok I'm a huge fan of both laser and microwave so I should have though to include that in my post. I agree that the transmission rate would be much faster, that it does use significantly less transmission power to accomplish the same job, and being mostly point-to-point it doesn't have the limitation of having to share frequencies with everyone else in the Solar system. Thanks for pointing that out. – Ian Moote Sep 11 '18 at 12:05

The smallest set of changes you could do, would be to switch from TCP/IP to UDP/IP. The biggest issue with TCP is that it needs to check back with the sender to ensure the packet has arrived. If it takes 10 hours one way, then its going to take 20 hours to know that the message you sent has arrived and if you need to resend packets.

With UDP this verification step is ignored. If I want to send a message, I can sent it in a fraction of a second. If it doesn't make it, the person who requests the data will simply request for it again. I don't need to maintain a connection for 20 odd hours, just to make sure the message has arrived.

You would also need to authenticate and encrypt your data with a shared key that will need to be determined before hand, similar to a SSH key because it would be too inefficient to encrypt things dynamically.

Added -Edit: The question asks for reliability, throughput and low latency. You simply can't have all of them. If you want reliability and high throughput, your not going to get low latency and if you want high throughput and low latency, its not going to be reliable. Its the triangle thingy where you can only really maximize two out of the three. If your physical layer is assumed to work just fine, then using UDP and pushing the rest of the logic into the application layer will provide you better results. The lack of handshaking and verification means your going to have the lowest latency possible, and throughput and reliability are going to end up being dependent on your hardware. An application designed to request for lost packets is still going to end up better than TCP because you only need to request for lost packets and skip the verification and initial handshake.

The Truth of the matter is no one protocol will be used. Protocols guarantee different things and serve different purposes. If you have a remote base/probe that takes 10 hours to communicate to, you don't want to wait 20+ hours to see the live video feed (Handshake, packet transfer and order guarantee will eat up all your time). Your going to use UDP to ensure that you have the video as quickly as possible (10 hours). Like wise, if your transmitting a file, you want reliability, and this can be added at the protocol level (There are many variations of UDP or just plain TCP) or application level. Finally if you want to transmit huge amounts of data, you want to deliver it physically, because you can almost always delivery huge amount of data faster if you physically move it (if you think data transfer over a line is faster your not thinking big enough).

• "If it doesn't make it, the person who requests the data will simply request for it again" - wait, isn't that just TCP again? UDP cannot fill in for TCP. UDP with homegrown retransmission rules to have reliability, ordering and error-checking will probably do much worse than TCP. – Bergi Sep 10 '18 at 13:15
• @Bergi No. Retransmissions do not convert UDP to TCP. One fundamental property of TCP is the establishing of a connection, and there's no point for a connection with a delay of hours. – maaartinus Sep 10 '18 at 15:42
• @Bergi The difference is that in UDP the retry logic is up at the Application Layer rather than the Transport layer (4-layer model, not 7-layer OSI). TCP makes sense for applications that don't want to have to re-invent that wheel, and will pay the extra overhead of the 3-way handshake and 4-packet teardown in exchange for letting the TCP code keep track of the fiddly bits. With a 20h lag, that overhead would be counter-productive. – Monty Harder Sep 10 '18 at 15:43
• @maaartinus Sure, retransmission is not the only feature that separates TCP from UDP, I just picked that from the answer. But what if I want to send large (possibly infinite) content that doesn't fit into a single UDP packet? If I need an interplanetary protocol with the TCP features, "use UDP" is not an answer. – Bergi Sep 10 '18 at 16:00
• @Bergi But I think you’re right that the answer needs to say what you would build on top of UDP, what features of TCP you’d build and how you’d do them differently than TCP, etc., rather than just something on top of UDP. – abarnert Sep 11 '18 at 16:21

Caching

The first person download the new Game of Thrones takes 20 hours. After that a copy is stored on the caching server and it only takes seconds for the second person.

Caching keeps the results of requests locally so it's slow the first time while it gets the information but much faster as it already has it for further requests. The server only hold X amount of data so the oldest requests drop off the end of the queue as it fills up.

The end result is the most common requests are stored locally and are much quicker and data transmitted is much less.

• Caching doesn't help to reduce RTT, nor the amount of round trips necessary fora handshake – dot_Sp0T Sep 10 '18 at 6:50
• No it doesn't but the hand shaking issues had already been discussed so there was no point making that my answer unless I wanted to repeat everyone else. In reality there will be a whole raft of changes needed to make it work of which hand shaking and caching would be an important part. – Thorne Sep 10 '18 at 7:11
• So, you want a HTTP layer on top of TCP? Yeah, that will work for hyperdocument transmission, but not really for other applications of TCP. – Bergi Sep 10 '18 at 13:17
• While extensive caching would be necessary, it does NOT help with any of OPs questions. – Hobbamok Sep 11 '18 at 16:36

You need to change the way your internet architecture is set up to have caching of entire websites

There's no reason to bother with lengthy downtimes on the internet, except in the form of messages sent from planet to planet. If the internet has a downtime of 20 hours just to load a list of webpages and another 20 hours to load one page, people just won't do it.

If you want people to use the internet, each colony needs their own servers to hold the contents of the web that they want to be able to see. When a colonist goes online, they are only really communicating with the local server. Local servers communicate through the satellite network by PUSHing updates to other colonies who download the updates. This way, browsing the web takes seconds, even though the news might be a few hours old, which can't be helped anyway. This update pushing process means the network is decentralized, and because local computers don't communicate directly access the internet, traffic is significantly reduced. If computers communicate directly with the internet, routers will not be able to handle all the traffic, especially if they are storing packets during downtime.

When servers communicate, all of the packages are pushed at once, and the connection is not kept alive. This protocol works with the packet storage idea proposed by other answers.

If you have multiple routing paths that the messages can be sent through, each router on the path sends the packets through all of the pathways available and the receiving computer takes the first one it gets and ignores duplicates. If the package is corrupted, it waits for a duplicate to arrive. If after a couple hours it has only gotten corrupted packets or no packets have arrived, it requests the packets again.

Messages can use a different protocol. Messages are sent from one colony's server directly to the destination server, not to any other servers on the network. When the receiving server gets the message, they push the message to the computer that receives it.

With these methods, servers can't afford the luxury of opening and closing ports. They always have to be listening for updates so they don't miss anything.

Benefits of this design:

Less computers sending packets over the interplanetary routers, dramatically reduces round trips, server always receives the message as fast as possible, no handshake necessary, multiple routing paths means the network can stand the loss of a few satellites, almost instant communication with the local server, ability to push updates instead of client requesting them, separate messaging protocol (no other colonies see your message to a different colony).

• So each colony has its own net, and between them there's an inter-net? Uh, that's how it already is working today. – Bergi Sep 10 '18 at 13:21
• @Bergi Some features of this net: each colony stores its own internet, packages are sent through multiple different paths for redundancy due to the inefficient nature of requesting packages, and because the internet is stored on a clony's server, requests are almost instant. – John Locke Sep 10 '18 at 15:22
• "It's own internet" - but that's a local area network, not an internet, and it's quite likely that many services are not available on it, e.g. when you want to do business with an other colony. – Bergi Sep 10 '18 at 15:34
• @Bergi Maybe my answer was not clear enough, each colony has its own server/database which people in the colony load pages from. When someone goes to SE, for example, and answers a question, the answer is sent from the colony's server to all of the servers in the other colonies' servers which update their databases to show that a new answer has appeared on that page. With this setup, loading a page is instant, but if someone in a different colony performs an action, there will be a delay before you see it. – John Locke Sep 10 '18 at 15:40
• @Bergi The OP said "No one faction has enough resources to build a communications system spanning the entire inner solar system... The competing factions settle on developing a collaborative communications system modeled on the Internet, where no one faction can be dominant." Each colony has only the pages it wants on its internet. If no one in the colony goes to example.com, there is no reason to use up space storing that website. Think of it as a very dynamic caching system, where the colony's cache is periodically updated with new data and the colony sends new data to the other colonies. – John Locke Sep 10 '18 at 15:54

Bandwidth

You haven't specified how much bandwidth you have.

You can broadcast absolutely tons of additional information if you have extra bandwidth. For example, interplanetary netflix you could broadcast 15 minutes of the 30 most similar films alongside the film you are watching when it comes to an end, so you can select another film to watch and begin watching it immediately. The same can apply to all kinds of data.

Prediction

Datablasting

You could also do something akin to a datablast from the 90s, where information would be displayed at high speed and the public would videotape it and replay it in slow motion to read it. Constantly be broadcasting all kinds of information continously and caching it, in case it is needed. Even with low bandwidth, any spare 'cycles' could be used to cram in additional information.

Remote Executability

Remote executability would be the ability to send a small program that can be executed on earth.

For example, you want to play interstellar chess with someone on Jupiter's moon Io. Instead of sending a move, only to find out 45 minutes later it was an illegal move because you forgot you were in check, it would be faster if a small chess program was uploaded and executed on both earth and Io. Then when an illegal move is made it can be validated or modified without the need to send it on.

This is similar to client side validation in Javascript, whereby you try to submit a form to sign up to something and forget to fill in your e-mail address, it will ask you to complete it before sending the form instead of sending it and getting an error back.

Another example of this is if a client requests information about the position of earth on a certain date. Rather than them send the request and 45 minutes later receive a response, they could instead receive a small executable program that will calculate this for them.

Caching

Obviously, caching data for re-use locally but on a wider scale, putting servers onto various planets/satellites and caching it in each of them. For example, the big News sites would be popular daily so this would be distributed and cached between all of the locations. Other data would also be cached, and kept based on views. This is very similar to how Amazon's warehouse system operated - items people are likely to buy are automatically distributed to warehouses using algorithms that predict people will buy the items, thus saving on shipping time.

I guess that one of the key things to note is the paradigm shift required in terms of developing the internet. It's not really a question of How do we deliver web pages and the current internet experience, it's more a question of How would the world wide web look if latency was crazy high?. You'd retrain your software engineers and rewrite all of your tools, and the internet would be mostly application based, you'd probably download the BBC News app and have it updated automatically every morning from a local cache, either downloading the entire site, or just browsing the entire site locally from a cache.

# IPTP (Interplanetary Transmission Protocol)

IPTP is a bi-directional, point-to-point, store-and-forward protocol, designed to be highly fault-tolerant.

IPTP Links are defined between planets such that at any given time there is exactly one transmitter on or in orbit around one planet streaming data to any given array of receivers on the other. (The active transmitter will change as the planet rotates and satellites revolve about it.) This stream must be able to multiplex a large number of different sub-streams of data (coming from many different sources on the originating planetary internet), which will themselves be queued up in buffers for actual transmission.

The overall stream will be broken up into "blocks" of a size appropriate to the quality of the link that are each individually encoded using Reed-Solomon error-correction, and additional "parity" blocks will be transmitted periodically, allowing reconstruction of blocks that exceeded the error-correction threshold of the RS code in use for that block. (IPTP allows for this block size to be changed as conditions warrant) Each block must be retained on the sending end until a Block ACKnowledgement (BACK) is received from the receiver.

For additional robustness, after a series of "rows" (N data blocks plus an XOR parity block of those data blocks) are transmitted, a "parity row" (constructed by XORing together corresponding blocks in M consecutive rows) is then transmitted. At the end of a group (called a "chapter") of L pages of M rows and N columns is a "parity page" (constructed by XORing together the corresponding blocks in all the pages). The entire chapter of (L+1)(M+1)(N+1) blocks must use the same block size and R-S encoding, but subsequent chapters can change the block size, as well as the values of L, M, and N, as conditions warrant. In general, L, M, and N will be larger when fewer blocks need to be re-sent.

Within a chapter, the sub-streams should be assembled in priority order to minimize the number of blocks that carry data of two or more different priorities. A block's transmission priority is equal to the highest priority level sub-stream it contains.

Prior to each chapter is a header defining those parameters. [The InterPlanetary Transmission Task Force says that future versions of IPTP may extend the parity system to "books" of K such chapters, incorporating (K+1)(L+1)(M+1)(N+1) blocks each. IPTPv1 defines K=1 with no parity, so a book has only one chapter.]

"BACK" metadata must be sent back from receiver to transmitter to acknowledge entire chapters as well as ranges of blocks within a chapter. Any blocks not BACKed that fall before the last block BACKed will have to be re-transmitted. The determination to re-transmit must not be made until the entire "book" has been received and decoded, as the parity blocks, lines, pages (and chapters) to allow a BACK to be fully reconstructed will not have been processed yet. Because a BACK itself occupies one or more blocks to be BACKed, there will always be something to BACK, creating an implicit "keepalive" between the nodes.

Metadata (including but not limited to the above BACKs) is the highest priority level for substreams, and therefore should always be the first thing in a book/chapter after the protocol header. The details of other QoS considerations are still being defined by the IPTTF.

Once the data stream is reconstructed on the receiving end, it can be de-multiplexed into sub-streams, each sent to its desired destination on the planetary internet.

• XOR parity, really? – Bergi Sep 11 '18 at 16:28
• I think the OP was more interested in how routing, caching, and dealing with latency worked, rather than what error detection/correction is used on the link layer. – Bergi Sep 11 '18 at 16:29
• Yes, XOR parity. It's fast and parallelizable, which is a must for a protocol that has to deal with a metric assload of data passing through it. Note that individual blocks use Reed-Solomon codes internally, but those individual blocks can be handed off to separate processors to handle error-correction at the sub-block level. Only those blocks that couldn't be corrected by the R-S codes would need the additional parity from the KxLxMxN arrangements. – Monty Harder Sep 12 '18 at 15:31
• The caching is also explained here. The entire stream of data going from planet A to B must be cached until it's BACKed. – Monty Harder Sep 12 '18 at 15:32
• I must have missed that in all the talk about pages, chapters, and books. Where is caching mentioned? – Bergi Sep 12 '18 at 17:01

### A complete overhaul is the smallest sane change

• With a latency of 10 hours, you surely don't want to establish any connection as it alone needs three packets, which means 30 hours wasted.
• TCP-like congestion control makes no sense. For maximum efficiency, you want to direct your dishes exactly to the party you communicate with. That's true for both the sender and the receiver (there'll be either a fixed setting like "this dish communicates with Pluto" or a pre-arranged schedule). This eliminates any congestion on the link itself. The link will always work with a fixed speed, unless broken.
• As the transmission cost is much higher than the storage cost, every sent packet will get also stored until acknowledged (many hours later).

I guess, reliable UDP comes closer to what's needed. Anyway, you can forget about using the network for browsing or alike. It will look more like SMTP. You send a message and it'll get delivered, possibly delayed by many hours due to retransmissions. You can have some client-server communication, but it'll look more like requesting a book from a library than HTTP.

• +1 for mentioning RUDP, -1 for the second point. Yes, there would be individual links between the colonies instead of a broadcast (OP already established that the link layer works fine), but no that does not avoid congestion. At some point, you used up the available bandwidth of your link, regardless of what physical layer it is. Did you confuse "congestion" with "collision"? – Bergi Sep 10 '18 at 16:22
• @Bergi I'm unsure about the wording, but no. There'll be no such thing on the point-to-point link. The sender will send with a fixed speed, there'll be no congestion-implied packet loss, no blocking of new connections (as there'll be no connections at all, and the throughput stays the same - opposing what Wikipedia says about congestion. Sure, there'll be queuing and delays, but on a different level. Note that on this time-scale, this may (and probably will) be even regulated via dynamic pricing. That's not TCP-like congestion control. – maaartinus Sep 10 '18 at 16:41
• Yeah, the physical sender will have a fixed speed - that's the bandwidth. But if multiple clients try to use that connection to send data, they might want to send more data than the connection is capable of. (Which might also occur dynamically anywhere in a routed network). So yes, you can use queuing instead of dropping the packets, but ultimately that's a congestion. You might be able to guarantee that no packets are dropped, but at some point the clients will need to send less data (to not grow the queue infinitely) or choose a different route - congestion control. – Bergi Sep 10 '18 at 16:49
• @Bergi I agree and have edited my answer. There'll be congestion in the network, just not on a link. As the link is much more expensive that storage, everything will get queued. There'll be no packet drops (with some exceptions), but there'll be dynamic routing and ranking and pricing. – maaartinus Sep 10 '18 at 17:01
• @maaartinus If you do this right, you do still have a form of congestion control, it’s just very different from the one in TCP. You can’t let the queue on the interplanetary link get too long (even with complicated TOS), so you need badkpressure on the intraplanetary network that will queue or reject packets before they get there, and ideally push that all the way back to the originating host. When you try to send a too-big message, you should usually get an immediate error. – abarnert Sep 11 '18 at 16:30