Subject: Re: IP-in-TCP?
To: Daniel Carosone <email@example.com>
From: Seth Kurtzberg <firstname.lastname@example.org>
Date: 02/02/2005 00:16:29
If he really means tunneling IP through TCP, that would be essentially
the same as the UDP case. If he means an IP layer that can be used just
like any other IP layer (meaning you could have nested TCP) then I agree
that you have a mess.
Actually, you have a mess no matter what you do.
I think if you get into a situation with packet disassembly/reassembly,
you would have all the problems you described plus a mess at that
level. So choosing a packet size that guarantees that this never
happens is a good idea. I don't know what DSL does with packet sizes,
but if the originating machine has packets larger than the usual
Ethernet (~ 1500 bytes), such as FDDI or CDDI or what all, you would
definitely want to reduce the packet size fo the smallest value that
occurs anywhere in the pipe.
Of course, since the routing isn't necessarily the same for all packets,
you can't even find that number definitively, but in practice I've found
that multiple routes for packets that are part of a TCP stream are rare.
I'm sure it's possible to think up lot's of other pathelogical conditions.
Probably a good thing to do is to establish a TCP connection, run it for
several hours, and see if the error rate is zero, or close to zero. If
so, then the nested recovery would still be nasty, but it might not
happen often enough to get into any endless loops or livelock situations.
Of course, I know nothing about the physical topology in question here.
der Mouse, can you provide those details? If the machine is on the same
subnet, or otherwise connected so that packet loss is unlikely, you have
one situation. If you have significant unreliability, then Daniel's
description of the outer TCP trying to recover while the inner TCP is
also trying to recover would get very nasty. Throw in any fairness
algorithms in the path, and it gets messier still.
The advise to not nest TCP if possible is certainly correct. I'm not
completely clear on how everything would get put back together with
Daniel's suggestion of how to use UDP, so I should go read some man pages.
What worries me about that solution is that it's fundamentally the same
as multicasting on a reliable subnet, and I've seen that develop
cascading failures that could never be worked out. On a local network
where multicasting is universally supported, the behavior would be
similar to UDP. If your situation is similar to the one I'm thinking
of, the likelyhood of getting into trouble depends very much on the
volume of traffic. If any part of the path is anywhere near saturation,
you could have major problems, such as getting behind and never catching up.
Of course you care about both the maximum burst rate and the maximum
steady state rate.
Daniel Carosone wrote:
>On Wed, Feb 02, 2005 at 04:41:57PM +1100, Daniel Carosone wrote:
>>Such a system will end up duplicating 'lost' packets most of the time,
>>but as long as you have more open tunnel streams than real ones (or
>>more tunnel streams than packets lost, scaled by some factor), the
>>inner TCPs shouldn't get stuck behind outer TCP recovery.
>Actually, I think the phrase I was looking for should be "more open
>tunnel streams than tunnelled packets in flight".