[Gllug] TCP acceleration over high latency sat links

[Andrew Farnsworth]

> -----Original Message-----
> From: Julian Somers
> Sent: 22 November 2004 15:07
> To: Greater London Linux Users Group
> Subject: [Gllug] TCP acceleration over high latency sat links
>
> Does anyone know about TCP acceleration?
>
> I have been playing with the implementations of TCP Vegas and TCP
> Westwood that are shipped with the 2.6.9 kernel. I'm trying to tune TCP
> to work with huge latency. Im using inmarsat MPDS (a 64k packet switched
> circuit over an inmarsat satphone) for outgoing data, and DVB on
> opensky/eutelsat for incoming data. (This box is going to live on a
> ship, in case you're wondering why I give myself this grief.) Round trip
> times are never better than 2300ms, and are often much worse.
>
> Vegas seems to help with outgoing data, increasing throughput by about
> 20%. But I am still unable to fill the pipe in either direction (64k
> outgoing, 1MB incoming). I believe that this is because TCP keeps
> decreasing the window because it interprets the latency as congestion.
>
> My questions for networking gurus out there are these:
> - Am I barking up the wrong tree? Is my assumtion that latency will
>   cause TCP to back off, correct?
> - How can I see what's going on? Are there any tools that will allow me
>   to see the detail of what's happening with slow start and
> window/buffer sizes?
> - Am I wasting my time tuning just one side of the connection? Would it
>   help to tunnel to another gateway on the other side of the satellites,
> send all my requests via that box, and implement the same TCP
> acceleration there for data coming back down?
> - How complicated is it to send the TCP data 'inside' another protocol?
>   There are commercial products out there that seem to get round this
> problem by encapsulating the TCP packets in another protocol. Mentat
> (http://www.mentat.com) makes boxes that convert to XTP/IP and back to
> TCP/IP on other side of the connection. Others do the same thing, using
> UDP instead of XTP.

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.

Andrew Farnsworth

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