[Gllug] TCP acceleration over high latency sat links

[Julian Somers]

On Mon, Nov 22, 2004 at 03:32:22PM -0000, Andrew Farnsworth wrote:
> Disclaimer: I have never done this, only read about it.
> 
>   My understanding is that you have to have support on both ends of the
> connection for this to work, usually by using something like a caching proxy
> at the far end that does all the internet communications for you, then
> communicates with you over a special connection, either customized TCP/IP or
> some other protocol.  This means that the local machine, when sending, does
> not wait for ACKs to return before sending the next packet, it just floods
> the pipe.  Then the remote machine proxies that and does all the normal
> TCP/IP communication with the net, it then pushes the data back to you in a
> similar manner, again not waiting for ACKs, it just floods the connection.
> Note that this requires support on both ends of the connection and in your
> case, support on both ends of each connection.  I know that several
> Satellite TV providers (DirecTV for example) supply up/down link satellite
> internet connections and you would normally get ping times around 2-5
> seconds and to combat this they provide custom software [windows only :( ]
> that does exactly what I describe above.  I believe that the software has to
> know the size of the pipe it is trying to fill, but am not positive about
> this.
>   If you tried to do this without support from the other end, you will end
> up sending special packets encapsulated in TCP/IP and will still be subject
> to the long latency times.  Alternatively, you can force your packet size to
> the largest possible and this should help, however, you risk killing your
> connection entirely in the case of a noisy signal.
> 
> 
>   Remember, this is not my specialty, this is just from some research I did
> for satellite net connections a while back for some rich person who wanted
> net connectivity from a moving custom bus.

Thanks for the info. I have been messing around with packet and buffer
sizes, and with web100, and have had some success, but only accelerating
the outgoing data. Looks like I will have to put a gateway at the dvb
hub to proxy everything and accelerate forward data. 

Did you have a tool in mind to "flood the pipe", without waiting for
ACKs? TCP Vegas does this, up to a point, by spoofing the ACKs, but if
there are heavier weapons out there...

I have a notion that the best performance would be gained from sending
all the data between my boxes and the gateway as UDP, and have it
translated at either end back into TCP. But I have no idea how this
would be done. Any pointers?

Thanks, JUlian

By the way, turning on vegas in kernel 2.6.9 (echo 1 >
/proc/sys/net/ipv4/tcp_vegas_cong_avoid) seems to have increased
outgoing throughput on my home dsl by about 20% :-)

> 
> Andrew Farnsworth
> 
> -- 
> Gllug mailing list  -  Gllug at gllug.org.uk
> http://lists.gllug.org.uk/mailman/listinfo/gllug
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug