[Mep-dev] TCP Performance Issues
Phil Karn
karn@ka9q.net
Tue, 25 Nov 2008 02:10:30 -0800
Paul Williamson wrote:
> Unfortunately, that's impossible in the large scale. Radio equipment
> gets turned off. RF paths come and go. Antennas get re-pointed to talk
> to a different station. Any of these things, and dozens of others you
> can think of, will cause the packet loss rate to jump to 100% on a
> particular link for an arbitrary and unpredictable duration. In a
> perfect world, we'd have protocols to cope with this.
That's not the kind of loss I'm talking about. The Internet protocols
*are* designed to deal with this kind of loss. That's why we use a
datagram network protocol and dynamic routing protocols. I'm talking
about a link that is up but has a high packet loss rate.
> Since the network partition may be of any duration, the best we can do
> is some flavor of store-and-forward.
Store and forward includes conventional IP routing. A packet comes in,
it's stored in RAM, a routing decision is made, and it's sent back out.
There's no conceptual difference between this and a BBS other than the
time scale. If you use a reliable link protocols (ARQ + FEC, or
whatever's appropriate for the link) the difference becomes even less.
> I have only a tiny familiarity with the DTN proposals, but my impression
> is that they're intended to solve a similar set of problems: long
> outages and intermittent connectivity. The bandwidth-delay product is
> not the right concept for modeling these scenarios.
>
If you mean discontinuous networking, yes, that's a qualitatively
different class of problems that's defined by the lack of a working
end-to-end path for periods much longer than the end-to-end propagation
latency.
Stock TCP was never designed for this, but in theory even it could work
if it were modified to be extremely tolerant, or at least aware of
predictable mechanisms that control connectivity (e.g., orbital geometry
for satellites or interplanetary spacecraft).
Practically speaking, here I concede a different approach is practically
required. But is this what we're talking about?