[e2e] TCP spoofing in overlay networks

[Jon Crowcroft]

an overlay that uses TCP is already doing multiple TCP hops - this
gives at least 1 advantage over a pure end2end TCP connection which is
that the steady state throughput for TCP is a function of 
1/rtt - but for an overlay the RTT concerned will be the maximum rtt
of overlay hops, not the end2end one - ofcourse, with some p2p
algoriths this might actually be longer than an end2end rtt:-)
but with most sensible overlay routing schemes it will be shorter...

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;)

i dont know if anyone has looked at that side of "hop-by-hop tcp"...

personally, i dont know why people use TCP
In missive <42253390.5080308 at cse.msu.edu>, Jonathan Shapiro typed:

 >>I recently had occaision to read a few papers about the practice of "TCP 
 >>spoofing" over satellite links---i.e inserting a proxy prior to the 
 >>satellite link to provide TCP feedback to the sender, effectively 
 >>splitting into two TCP sessions connected in tandem. I was wondering if 
 >>anyone had ever proposed a similar idea to improve TCP throughput in 
 >>overlay networks over terestrial links.
 >>
 >>/jonathan shapiro
 >>

 cheers

   jon