[Gllug] TCP acceleration over high latency sat links

[Julian Somers]

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. 

Thanks, Julian 


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