Daniel,

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".
>
>--
>Dan.
>
>------------------------------------------------------------------------
>
>!DSPAM:42007477325971753810845!
>