[Mep-dev] TCP Performance Issues

[Bob McGwier]

I think there is a missing of the point going on.

DTN as implemented in the code base I have been pointing to is link and
network layer neutral for the most part.  It is a store and forward
mechanism and runs on top of the transport.  There can be good and bad
choices for the transport mechanism in any store and forward mechanism and
it will not fix a bad choice.

I should perhaps let some of the cat out of the bag for the purposes of full
disclosure.  Preston Marshall is a friend and colleague.  

http://www.darpa.mil/STO/strategic/wireless.html

His support in DARPA for delay and disruption tolerant networking and the
money he is pouring into it are having a big impact on the research.

Preston is building a "WNaN SDR/CR" for all sorts of reasons.  Charles
Clancy of LTS, Tom Rondeau and I (IDA/CCRP), and Preston are all supporters
of the IEEE DySPAN work, WNan, and more.  White space, cognitive radio, and
DTN go together!  The interplanetary IP work Preston supported through NASA
as a later addition, long after delay and disruption tolerant networking
support at DARPA were well under way.  

Preston is doing his Ph.D. for Linda Doyle at Trinity College (Dublin).  Tom
did his post doc with her before I hired him.  We are looking out years into
the future, for different reasons, but with a set of common ideas and lots
of arguing going on. ;-).

Yes TCP is a good protocol. Who the heck ever said it wasn't?.  Yes it will
be needed because we really must insure end to end integrity of the data in
ENCOMM, whatever the data is and TCP is certainly the easiest thing for us
to use for now.  DTN is one proposal for allowing for weird routing to help
the overall system when you have tough delays or disruptions and you insist
on getting the data through, even if in drips and drabs.

Tim seems to have specific objections to DTN as currently captured in RFC's,
Darpa WNan work, etc. as the "store and forward" mechanism.  Fine.  If we
want to reinvent the wheel when it comes time for us to insist on store and
forward for data that just must get through and we have to allow for balky
or disrupted transport/network/link I will resurface the suggestion.  This
suggestion is really independent of the hardware and much of the software
needed and I personally consider them more important than this distraction
for the moment.  I will table the suggestion as an unnecessary disruption.
We need to build a hardware and software common platform for experimentation
and this can wait.

By the way, Tom won the council of graduate schools best Ph. D. thesis award
in math and engineering for 2007/2008 academic year.  He has been granted
the first big patent in cognitive radio (though he knows how much I hate
this kind of patent, it is part of the engineering culture these days).  Joe
Mitola, fred harris, John Chapin (Vanu SDR CTO, SDR forum chair), Johnathan
Smith (U. Penn./DARPA) are all now adjuncts at CCR-P in support of the work
Clancy and I are doing.  I am not just a loud mouthed red neck with too many
opinions.  

To my US friends: Happy Thanksgiving!
Bob
N4HY

ARRL SDR Working Group Chair
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
" Don't despair, not even over the fact that you don't despair. ", Kafka

-----Original Message-----
From: mep-dev-admin@uppermeadow.com [mailto:mep-dev-admin@uppermeadow.com]
On Behalf Of Phil Karn
Sent: Tuesday, November 25, 2008 4:58 AM
To: Dave hartzell
Cc: mep
Subject: Re: [Mep-dev] TCP Performance Issues

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.

_______________________________________________
Mep-dev mailing list
Mep-dev@uppermeadow.com
http://lists.uppermeadow.com/mailman/listinfo/mep-dev