[e2e] A simple scenario. (Basically the reason for the sliding window thread ; -))

[David Borman]

There are real-world scenarios where the insertion of a splitter into  
a TCP path does make a lot of sense.  The cases I am familiar with  
all are necessitated by a severe mismatch in MTU, buffering and  
performance, the splitter is in the only path by which the packets  
can travel, and it is sitting at the crossover between the two  
disparate paths.  In the specific case that I dealt with, the  
splitter's main purpose was to change the TCP MSS option, send larger  
window sizes, and buffer/repackage data.

Getting the splitter to operate well takes some work.  It has to  
maintain state for the connections in both directions.  Besides  
acking and buffering data in both directions, and possibly  
repackaging data between the two sides, it also has to make sure that  
it synchronizes control events between the two halves so that neither  
endpoint gets into a state of believing that the connection has  
completed successfully when it hasn't.  And there will still be  
failure modes that you wouldn't get with a straight TCP connection,  
but most of them are when the connection doesn't complete successfully.

But in general, deploying a splitter where there is a possibility  
that packets can take an alternate route around the splitter, or  
where you do not have some degree of control over one side of the  
network seems like a bad idea to me.  A splitter should not be a  
general purpose device, it should be tied to the unique  
bandwidth*delay mismatch of the problem that is being addressed.

A TCP splitter that is *not* a NAT box operates at the TCP layer, and  
should not require any changes to the content of the TCP data stream,  
whereas an application level proxy often requires that the proxy has  
knowledge of the particular application, and may have to modify the  
data stream.

			-David Borman