Wednesday, 17 July 2013
You canna' change the laws of physics, cap'n
They seem to have rather quietly created a rather impressive service. For around £25/month for the lowest residential tariff you can get 20Mb/s down and 6Mb/s up.
It was easy to set up, in fact, after playing in the car park yesterday, today I simply plonked it on the gravel by the office and turned it on and it worked first time before I had even aligned it. A bit of tweaking got the SNR from 2 to 10dB, but it was that easy.
Plug a laptop in, download a file, and see and average over 20Mb/s transfer speed. Wow!
But, those damn physics police insist that you can't go faster than the speed of light, bugger. The round trip pings are around 700ms. Bear in mind that it includes switching delays and the up-link being in France (we think).
This is a problem. TCP does not do 20Mb/s over 700ms. Do the sums. It means 1.7MB of transmit buffer at the sender per TCP session. I checked, and the config on a typical linux box was 128kB. You can put it up, and use window scaling (TCP only does 64KB without it) but that would mean reconfiguring every server on the internet to which you wish to communicate.
The 700ms is a big issue. Consider the normal "go to a web page", which includes a DNS exchange, an initial SYN/SYN+ACK exchange, and then several stages of "slow start congestion window" on TCP to get to filling its tx buffers before hitting a limit of maybe 1.5Mb/s.
So, the service must be doing something special. What you can do is fake the TCP session at both ends, telling the sending server that the packets have, in fact, arrived at the laptop, when they have not. You then send them (reliably) over the satellite link, with your own acks and retries somehow. It means buffering in the network, and is not very nice as the sender gets a false sense of security, but for most practical purposes that is not important. It allows the transmission over the high latency link to be managed in a different way that is fine tuned to allow for the high latency, presumably with selective resends and so on.
Of course, as soon as we get clever and tunnel traffic over the link, we lose that. Hence getting a little over a 1.4Mb/s transfer rates per session. We are being clever as we want to use a mobile and/or slow ADSL link to support the satellite by sending small packets (ACKs, DNS, etc) over the low latency link. This reduces the round trip latency which helps, but still does not solve the whole TCP window and startup issue.
So, next challenge, we have to make a system to do this TCP spoofing logic ourselves. Not a small project, but the rewards should be a stunning service with low latency interactive response time, but high throughput in the middle of nowhere... I'll post when we get the time to do this.