Your Cross-Region Transfer Is Window-Limited, Not Bandwidth-Limited

A bulk transfer between two continents is not limited by the bandwidth you paid for. It is limited by how many bytes the two endpoints are willing to keep in flight at the same time, and by default that number is far smaller than the link can carry.

Here is the scene that produces most tickets of this shape. An engineer rents a server with a 30 Mbps port, runs a speed test against a nearby city, and reads 30 Mbps. Satisfied, they point a replication job at a bucket eleven time zones away. The job reports 7 Mbps. Nothing is broken. No provider is throttling anything. The port is idle most of the time, because the two ends keep stopping to wait for each other.

This is the bandwidth-delay product, and the uncomfortable part is that it is a division problem. You cannot buy your way out of it with a faster port, because the port speed is not in the numerator.

Throughput Is a Division Problem, Not a Bandwidth Problem

For a single TCP connection, sustained throughput has an upper bound that looks like this:

throughput = bytes in flight / round-trip time

That is Little's law applied to a pipe. "Bytes in flight" is the amount of unacknowledged data the sender has pushed onto the network and the receiver has committed to accepting. "Round-trip time" is how long it takes an acknowledgement to come back. Divide one by the other and you get the rate the connection can sustain, no matter how fat the pipe underneath it is.

The connection's capacity to hold data, meanwhile, is the bandwidth-delay product:

BDP = bandwidth x round-trip time

At 30 Mbps and a 150 ms round trip, that is 30,000,000 x 0.150 / 8 = 562,500 bytes, or about 549 KiB. The pipe can hold 549 KiB in transit. If the sender only puts 128 KiB on the wire before stopping to wait for an acknowledgement, the pipe runs at roughly a quarter of its capacity and the other three quarters are simply wasted. The bytes are not being delayed. They are not being lost. They are not being sent.

Notice what is absent from both formulas: the port speed does not appear in the throughput equation at all. It appears only in the BDP, which tells you how big a window you would need in order to use it. A 100 Mbps port and a 30 Mbps port across the same 150 ms path move within a few percent of the same number of megabytes per second, for the same reason.

Where 128 KiB Comes From, and Why It Is the Number That Bites

The default is not arbitrary, and it is not a bug. It is 1990s arithmetic that survived into 2026 because it is still correct for the case it was designed for.

The TCP header's window field is 16 bits wide, which caps a plain advertised window at 65,535 bytes. That is fine on a local network: at a 1 ms round trip, 65,535 bytes in flight already sustains over 500 Mbps. It is hopeless on a path that crosses an ocean.

Two mechanisms exist to lift the cap, and both have conditions attached.

Window scaling. RFC 7323 adds a 14-bit scale factor that multiplies the advertised window. The theoretical ceiling is 65,535 x 2^14 = 1,073,725,440 bytes, just under 1 GiB. The option is negotiated during the handshake, so both ends must offer it. It is enabled by default on Linux (net.ipv4.tcp_window_scaling = 1), which is why this problem usually shows up as a tuning problem rather than a protocol wall.

Buffer autotuning. The kernel grows a socket's buffer to match what the path needs, but only up to a ceiling that depends on installed memory. On Linux, net.ipv4.tcp_rmem is a three-number vector: minimum, default, maximum. The minimum is 4 KiB. The default is 131,072 bytes, which is what produces an initial advertised window of 65,535. The maximum sits somewhere between 131,072 bytes and 32 MiB depending on how much RAM the machine has. The send side, net.ipv4.tcp_wmem, defaults to 16 KiB and maxes out between 64 KiB and 4 MiB, and it does not override net.core.wmem_max.

So on a freshly provisioned cloud instance you get two numbers that matter. The 131,072-byte default is the one that governs a connection that has just started, and it is the reason an untuned transfer is slow. The RAM-derived maximum is the one that governs a connection the kernel has decided to grow, and it is the reason a tuned transfer sometimes refuses to get faster.

Three footnotes that are easy to miss.

Autotuning can only grow a buffer up to the maximum in tcp_rmem (net.ipv4.tcp_moderate_rcvbuf defaults to 1, and its stop condition is that third value). Setting the socket option SO_RCVBUF or SO_SNDBUF explicitly turns autotuning off for that socket, so a well-meant application-level buffer override can freeze the window at whatever value it was given. And net.ipv4.tcp_limit_output_bytes, which caps how much a socket keeps queued locally, defaults to 4 MiB - comfortable at a 150 ms round trip, but the first thing to check on a very long haul.

The Crossover Sits at 34.95 Milliseconds

Ask a specific question and the answer becomes a distance. At what round trip does a 128 KiB window stop being able to fill a 30 Mbps port?

131,072 bytes x 8 / 30,000,000 bits per second = 34.95 ms. That is the crossover. Below it, the default window is sufficient and the port is the binding constraint. Above it, the window is the binding constraint and the port is decoration.

A 34.95 ms round trip corresponds to about 17.5 ms one way. Light in fibre travels at roughly 200,000 km/s, so 17.5 ms is about 3,500 km of path. That is the distance at which the default configuration of a 30 Mbps server stops being able to use the bandwidth it was sold.

The table below is the same calculation swept across realistic round trips. Readings are for a single un-tuned TCP connection on a 30 Mbps port.

Read the last two columns together and the commercial implication is blunt. Going from a 30 Mbps port to a 100 Mbps port on a 180 ms path takes you from 5.8 Mbps to 5.8 Mbps. You are buying a wider road on which the same number of cars are driving, because the cars are what is scarce.

The Second Ceiling: Loss Makes It Quadratic

Raising the window is not a complete fix, because a larger window means more packets in flight and therefore more packets exposed to loss at any moment. The standard model for what loss does to a single TCP connection is the Mathis equation:

throughput = 1.22 x MSS / (round-trip time x square root of loss rate)

With a 1,460-byte maximum segment size, this is what it produces:

The exponent is the story. A loss rate of one packet in a thousand, which looks like clean networking on a monitoring dashboard, cuts a 150 ms connection to 3 Mbps. Raise the window and you improve throughput only until the extra packets in flight start colliding with the loss rate. This is why buffer tuning delivers a step change and then plateaus, and why the plateau moves down as the path gets longer.

Loss-based congestion control also explains a behaviour that looks like a provider problem. When a connection is loss-limited, its throughput is choppy: it ramps, drops, ramps again. When it is window-limited, throughput is flat and low. Flat and low means tuning. Sawtooth means loss.

Three Signals That Tell You Which Ceiling You Hit

You do not need a packet capture to tell these apart. You need one command and one arithmetic check.

ss -ti on the sending host during a transfer prints, per connection, the current congestion window, the smoothed round-trip estimate, the retransmit count, and whether the socket is congestion-window-limited. That single line distinguishes the three cases.

The arithmetic check is the one worth doing before anything else: take measured throughput, multiply by measured round trip, and compare the result to the window you believe is in use. If the product lands on the default, you have found the ceiling. If it lands somewhere above the default but below your buffer setting, the buffer is not the constraint and you should stop tuning it.

Four Explanations That Are Usually Wrong

Slow cross-region transfers attract confident diagnoses. Most of them are testable in ten minutes, and most of the time they are wrong.

There is a cost argument buried in the first row that is worth stating plainly. Upgrading the port on a high-latency path is the most expensive way to buy nothing. Upgrading the instance so the kernel's autotuning ceiling is higher has a similar shape: a larger machine raises tcp_wmem's maximum, which helps, but it does not raise the 131,072-byte default that governs the first seconds of every connection, and it does nothing at all about loss. Both purchases are sometimes right. Neither is the first move.

The Fix List, in Order of Cost

Work down this list. Stop when the measured throughput stops improving.

1. Confirm scaling is actually in use. ss -ti shows a window far above 65,535 on an established connection when scaling negotiated. If it does not, the option did not survive the handshake and no amount of local tuning will help.
2. Raise the buffer within the real ceiling. Read the current maximum with sysctl net.ipv4.tcp_rmem and net.ipv4.tcp_wmem; if the last value is under what the path needs, raise it. Then confirm the transfer changed, because a change in a sysctl that does not move a number is not a fix.
3. Parallelise. N streams each carry their own window, so aggregate throughput rises roughly with N until the port or the loss rate becomes binding. This is the only step on the list that also fixes the loss-limited case.
4. Send less. Delta sync, compression, and never re-fetching what has not changed attack the numerator differently: the fewer bytes have to cross, the less the ceiling matters.
5. Move the computation to the data. If the job is a join between a dataset in one region and a service in another, running it next to the larger input is a topology change, not a network change. It is usually cheaper than any of the above.
6. Reconsider the topology entirely. Replication that crosses an ocean every hour for a dataset that changes by megabytes is a design decision, not a bandwidth shortage.

Estimating a Transfer Before You Start

The four-line worksheet is the whole method. Do it before the first byte moves, and you will know within an order of magnitude whether a job is a two-hour job or a two-day job.

1. Size in bytes.
2. Measured round trip to the destination, not ping to the nearest city.
3. Bytes in flight that the configuration will actually permit. Assume the default until you have changed it, and remember that SO_RCVBUF disables autotuning.
4. Hours = size x 8 / (bytes in flight / round trip) / 3600.

Run the arithmetic on 100 GiB and the shape of the problem appears immediately.

Two habits make this worksheet reliable. Measure round trip to the actual destination host, because the number you need is the one your transfer will experience - the discipline is the same one used for measuring exchange API round-trip time before relocating a trading bot. And decide the aggregation question separately: how much monthly volume a port can carry is a different calculation from how fast one transfer will run, and the two are frequently confused. The first is covered in how much bandwidth you actually need; this article is about the second.

The Floor You Cannot Negotiate

Everything above is a software ceiling, and software ceilings can be moved. Underneath them is a physical one that cannot.

Light in fibre travels at about 200,000 km/s, which is 5 microseconds per kilometre. A round trip is there and back, so the floor is 10 microseconds per kilometre of path, before any router, any queue, and any congestion. That yields the following minima from a Hong Kong node.

Compare the fourth column with the port sizes sold on entry tiers and the selection question answers itself. If your counterparties are in Taipei, Manila, or Ho Chi Minh City, the distance is short and the default configuration is not a problem. If they are in Frankfurt or Los Angeles, the distance alone roughly halves your achievable rate before any tuning, and the floor does not move because you bought a bigger instance.

This floor is also the reason the topic keeps mattering. Geoff Huston's review of the Telegeography keynote at NANOG 98, published on 28 October 2026, puts international bandwidth demand growth at about 30% a year: roughly 2 Pbps of additional in-service international capacity per year today, rising past 10 Pbps per year by 2035. The same review notes that the four largest hyperscalers now fund 38% of submarine cable investment privately and participate in a further 25% through consortia - 63% in total - and that the transatlantic route is 85% privately funded.

The other half of the picture is that the physical plant is ageing. An earlier APNIC analysis, published 14 October 2026, counts about 1.5 million kilometres of subsea cable across 607 in-service systems, finds that 86% of faults are caused by fishing activity or anchoring, and records a longest single repair of 947 days. Around 60 vessels worldwide are capable of doing the work, and roughly a quarter of current cable kilometres - about 845,000 km - is expected to be retired by 2030. That is the supply side of every long-haul transfer budget written this year. The floor is a property of where the two ends are, and it is not going to move.

When the Constraint Is the Node, Not the Wire

The analysis above turns into a purchase decision at exactly one point: whether your round trip falls below or above the crossover for the entry tier you are considering.

The Hong Kong lightweight tiers on the Hong Kong node cloud server page each ship a 30 Mbps outbound bandwidth allocation, from the 1 vCPU / 2 GB / 40 GB entry at $6.75 per month up to the 4 vCPU / 8 GB / 120 GB tier at $24 per month, with included monthly traffic rising from 1 TB to 4 TB across the five tiers. All five carry a renewal price equal to the first-term price, which matters for a replication job you intend to leave running. The page also lists five enterprise-grade configurations from $20.32 to $192.89 per month on 5 to 50 Mbps allocations with unmetered traffic, alongside a 99.95% availability commitment and 17 or more availability zones.

Read those against the crossover table. A 30 Mbps allocation stops being the binding constraint at about a 35 ms round trip, which is roughly 3,500 km. Eight of the zones on that page sit inside that radius from the Hong Kong node - Taipei, Manila, Ho Chi Minh City, Bangkok, Jakarta, Singapore, Tokyo and Seoul - and for those destinations the 30 Mbps port is genuinely the limit, so the entry tier is a coherent purchase. For Frankfurt, London, Los Angeles or Sao Paulo it is not, and no tier on the page changes the arithmetic, because the constraint there is the window and the distance rather than the port. What the Hong Kong location does buy in that case is the shortest path to the Asian destinations that are within reach of the crossover threshold in the first place - which is the same structure examined, from the latency side, in why region choice is an arithmetic problem.

For workloads where the remote endpoints are far away, the honest answer is that the topology is wrong rather than the server too small. Move the compute, cache the working set locally, or accept the transfer time and schedule around it. Where a single long-haul session does have to complete in a predictable window, the lever is streams and congestion control rather than port width - a distinction with the same shape as the one in the four lines of a game server's latency budget, where the term people measure is usually the smallest one.

Frequently Asked Questions

Why is my speed test fast but my transfer slow?

Because they are not measured against the same destination. A speed test almost always targets a nearby endpoint, where the round trip is small and even the default window saturates the link. The transfer crosses a continent. Run the speed test against a host at the transfer's destination and the two numbers will agree.

Would a larger port fix it?

On a long path, no. The achievable rate at an un-tuned 128 KiB window is independent of port size, so on a 180 ms path a 30 Mbps port and a 100 Mbps port both deliver about 5.8 Mbps. A larger port only helps after the window and loss limits have been raised above where the port becomes the constraining factor.

Is 30 Mbps enough?

It depends on distance, not on the number. The question to ask is whether the destination is inside roughly 3,500 km. Inside that radius a 30 Mbps allocation is usable in its default state. Beyond it, expect to get a fraction of the advertised rate per connection until the window is raised - and expect the fractions in the crossover table above.

Do UDP-based transfer tools avoid this?

They avoid the specific mechanism, because there is no advertised TCP window to be the bottleneck. They do not avoid the physics or the loss. A well-implemented UDP transfer protocol actively manages its own send rate against measured capacity, which is exactly the job TCP's window and congestion control would otherwise do badly on a long path. The floor in the region table applies to both.

Why do multiple streams help when one connection will not go faster?

Because each connection carries its own window, its own congestion state, and its own loss recovery. N connections put roughly N times as many bytes in flight, which is the quantity that was capping the single stream. The gain continues until the port or the path's loss rate becomes binding - which is why parallel transfer tools tend to hit a plateau of their own rather than scaling indefinitely.

Getting the Constraint Right Before You Buy

The reason this topic keeps generating support tickets is that the failure looks like a capacity problem and is in fact a configuration and distance problem. The port is idle. The provider is doing nothing wrong. The link is not congested. What is missing is bytes in flight, and the fix is a division you can do on paper in about two minutes.

Measure the round trip to the real destination. Compute window divided by round trip. Compare the answer to the rate you are seeing. In most cases the two will match within a few percent, and the argument is over. If your destinations are inside about 3,500 km of a Hong Kong node, an entry tier with a 30 Mbps allocation in its default state is the right shape of purchase. If they are not, the honest recommendation is to change the topology or the schedule rather than the plan, and to spend the tuning effort on streams and congestion control where the arithmetic actually rewards it.

SurferCloud runs 17 or more availability zones, with the Hong Kong node anchoring the regional map published on that page. The lightweight Hong Kong tiers start at $6.75 per month and renew at the same price. If you are sizing a replication job and want the zone list next to the crossover table above, the Hong Kong node cloud server plans are the place to start.