[Mep-dev] TCP Performance Issues

[Dave hartzell]

On Mon, Nov 24, 2008 at 9:14 AM, Timothy J. Salo <salo@saloits.com> wrote:

> Latency, in and of itself and in the absence of errors, is
> pretty much _not_ an issue for TCP.  People have made
> TCP run at full speed over 622 Mbps GEO satellite links.

Actually, modern TCP implementations (BIC, CUBIC, FAST) can go several
Gbps over international links....granted that is only sometimes half
the GEO RTT, but it is possible...

> This leads to the question: How can you make TCP perform
> well over lossy paths that may also have high latencies?

The big question in my mind is, what is the application?  Real-time
video won't benefit from TCP, it would be a hindrance.  There are
probably better ways to guarantee file delivery over large, fat pipes
as well.

> Another approach is to use a performance-enhancing proxy
> (PEP).  PEPs essentially break the end-to-end TCP connection
> into several concatenated connections.  The connection that
> runs over the lossy link assumes that lost packets result
> from transmission errors, rather than from network congestion.

These are interesting, but adds complexity and possibly additional
devices to the network.  Unless you can get the proxy to run on the
hosts, and intercept TCP at the source and destination hosts.  But
then why not try to use a different protocol in the first place?

> The MEP won't have these long latencies, but I hope that
> the knowledge gained from the MEP project will be useful
> to an ACP or other satellite-based project.

Any idea what latencies we're talking about?

> Note that this e-mail is only a terse primer on TCP performance.
> I will talk about my views on the DTN protocols and the MEP
> project in a future e-mail message.

Thanks for the note, I was kind of waiting for this thread to get started...

TCP can perform well on wireless links, but the rest of the time it
can drive you crazy!  Unless you use the Web100 Linux kernels, TCP
really does a good job of hiding the inner workings from the user.
Some of the later Linux kernels have better session statistics
available to user-space.

Take it from someone who spends a _lot_ of time trying to make
supercomputers talk to each other over long, fat pipe.....find an
alternative to TCP, at least for large transfers wanting to consume
the link.  TCP will work fine for small transfers, but for dozens of
megabytes over long pipes, it could prove to be a real challenge.

73,

Dave
AF6KD