[Mep-dev] TCP Performance Issues

[Phil Karn]

On Mon, Nov 24, 2008 at 10:07 AM, Dave hartzell <hartzell@gmail.com> wrote:



    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.


It's conventional wisdom that TCP is always bad for any kind of
real-time streaming, but I disagree. It depends on the numbers, most
specifically the allowable latency.

If the stream is one way, e.g., broadcast TV, then end-to-end latency is
not especially important. In real broadcast networks it is at least
several seconds and nobody will notice unless somehow they have an
independent direct connection to the source, or if they're watching the
ball drop on New Year's Eve with a good watch.

These several seconds can buy you many good things. Compression works
better when you can do it over a large data window. FEC can benefit from
deep interleavers that make coding very robust to deep fading. And you
can use ARQ, e.g., TCP, to recover from the occasional lost packet. You
just have to do it within your latency budget, whatever it is.

Most so-called "Internet Radio" services use TCP with long buffers and
they work just fine. I certainly prefer it that way instead of using UDP
and short latency that results in a lot of gaps in the stream.

Only in interactive streaming, e.g., full duplex phone calls, is latency
a tight constraint. Here TCP is usually a bad idea, but again not always
-- if the round trip time is significantly less than the latency
constraint, TCP might well be able to do at least one retransmission
within the latency budget.


    TCP can perform well on wireless links, but the rest of the time it
    can drive you crazy!


If it's not performing well on wireless links, then fix the link --
don't tamper with TCP except to ensure that the window is big enough.


    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.


I disagree. *Bad* TCPs perform poorly over long fat pipes. But unless
the transfer is very short, there's no reason why a modern TCP can't
fill the entire pipe. If the transfer is short, you can make one other
tuning modification: increasing the slow start quanta to get the
transfer going more quickly when the pipe has a long bandwidth*delay
product. If your transfer is *very* short, e.g., one packet, use UDP.
That's what it's for.