The other thing to note is that geographic topology doesn't equate to network topology.
E.g.: my last mile broadband provider is ISP A, the content I would like to download is in ISP B. A & B are in the same city BUT don't peer well with each other; meaning a packet destined for ISP A from ISP B might go halfway around the world via multiple networks before reaching you, and hence you would be looking at an order of magnitude more in terms of latency than you would actually expect.
In such cases, it depends more on who you buy last mile bandwidth from, and what peering relationships they have in place, rather than the physical distance.
Agreed. A better title might have been "The surprisingly significant effect of latency on download speed"... The author starts with the assumption that bandwidth should be the primary determinant of download speed, but it turns out that latency is the primary determinant for some connections, due to the TCP implementation.
That's wrong, actually. Getting high throughput in the face of high latencies is a solved problem, and the solution is called "buffering". TCP does this just fine, and was designed to do this from the beginning.
The problem is that the buffer isn't big enough. Standard TCP windows top out at 64kb due to field sizes in the header. This was a lot of data to be going over the wire in the days of 56k frame relay lines. Unfortunately, in the modern world a connection with a round trip latency of 200ms (not uncommon) and a bandwidth cap of 10Mbps (ditto) is going to need four times that much data "stored" on the wire. The TCP headers don't allow for that, so the transmitter needs to wait to send new data until the long-delayed ACKs come back from the receiver.
As the article points out at the bottom, there is a "window scale" option to IPv4 that allows for larger windows that is reaching common deployment, and of course IPv6 doesn't have the size limitation in the first place.
* there is a "window scale" option to IPv4 that allows for larger windows that is reaching common deployment*
I am curious to know how common this deployment is? In most cases you are still OS bound in terms of TCP window sizes, that being 2 in Windows and 3 in Linux to start with. How many people do you know that really tweak this setting?
Windows Vista supports automatic window scaling adjustments, supposedly. That probably counts as "common deployment," but I don't know if that's what he meant.
I used to use the freeware "Dr. TCP" program to adjust the TCP receive window scaling on Windows computers, probably as long as seven years ago. I'm sure that was common among professionals, enthusiasts, and on-line gamers. Less common for Joe Six-Pack, I'm sure.
Right, when I said "the TCP implementation", I mean the implementation of TCP that doesn't allow large enough window sizes. As you correctly point out, there are other TCP implementations that don't have this problem.
An interesting fact that we teach in 6.033 is that of the Boston<->San Francisco packet round trip time, half of that time is spent by light propagating through fiber, and half of it is spent in routers.
I can't tell if you're being sarcastic or not. Cisco routers, at least at the level I've been exposed to, don't have particularly good switching times. In point of fact, switching an IP header through a few-hundred-thousand-entry routing table is something that any desktop CPU can do in a microsecond or so. Companies like Cisco have managed to convince a lot of people that routers are these hugely complicated devices. They aren't.
The hardware side of long haul fiber networking is where the voodoo is. Routing? Not so much.
Sorry, I don't know much about the innards of routing hardware. I do know that doing all the routing in a time equal to the propagation delay of the light is pretty damn impressive to me.
I recall that all TCP versions after Vegas or Reno use pipelining to increase transfer speed. They send more than one segment before waiting for the ACK, and this of course multiplies the transfer rate by the number of segments. However, some TCP implementations either never initiate pipelining (it was the case of Windows XP) or use a low limit of 8 to the number of maximum outstanding (non-ACKed) segments, which does not push TCP to its potential.
I would have been a lot more surprised if download speed increased with distance.