[e2e] TCP spoofing in overlay networks

[David P. Reed]

Jon Crowcroft wrote:

>the effects of localizing loss recovery to an "overlay hop" will be
>more complex to evaluate - it isnt obvious whether this will have a 
>benefit or not (compared say to lowish latency wide area wireless
>links, where localizing the recovery through a TCP splice/proxy can be
>good, just as link layer ARQ or FEC to recover from loss on a hop can
>be good, in some cases - not all) - in the overlay case, you are stuck
>with the whole TCP behaviour when you do localized recovery on the tcp
>hops - so you might end up with lots of seperate slow starts operating
>(i.e. you are at the mercy of many unsynchronised TCP machines;)
>
>  
>
Au contraire, there has been lots of experience running TCP over 
"reliable links". Lots of experience in the field with using frame relay 
as a "hop", and turning on end-to-end reliability by accident, suggests 
that the underlay TCP will interact with the overlay in a disastrous 
postive feedback control loop creating unstable end-to-end behavior.   
It is *essential* that the underlay TCP *not* try to hide congestion, 
which is signaled by packet drops.   In other words if you are spoofing 
IP with TCP-based links, you have to create a situation in which the 
underlay does not allow its buffering to expand elasticly.