Skip to main content
Worldbuilding

Return to Answer

replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link
Community Bot
Community Bot
  • 1

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. (RFC1323RFC1323 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.)

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.)

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.)

added 240 characters in body
Source Link
Peter Cordes
Peter Cordes
  • 964
  • 7
  • 12

(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.

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.

(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.

Source Link
Peter Cordes
Peter Cordes
  • 964
  • 7
  • 12

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.)

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.)