[e2e] TCP spoofing in overlay networks

[Jonathan Shapiro]

Joe Touch wrote:

>
> TCP 'spoofing' of this sort is basically what TCP Splicing does; there
> are numerous problems with this - notably that it breaks the E2E utility
> of TCP (getting an ACK doesn't mean the other end got the data!), as
> well as challenges when the window sizes of the two TCPs differ.

I hope I am not rehashing an old debate on this list, but did the 
breaking of E2E semantics and mismatched window sizes prevent the 
deployment of spoofing/splicing for satellite links? (I'm genuinely 
curious, having only been recently exposed to this work.) If these were 
not considered insurmountable problems in that context, why should they 
be insurmountable for overlay networks?

> As to whether this is an overlay or not, I don't see how 'overlay'
> related. You're just spoofing a TCP connection; overlays (IMO) are
> defined by tunnels. There's no tunnel here (unless you're saying you're
> tunneling over TCP, which is a bad idea for numerous other reasons).

I guess I have a more inclusive definition of 'overlay' in mind. I would 
define an overlay network is a graph whose vertices are a set of 
end-hosts and whose edges are a subset (not nec. a proper subset) of the 
edges in the complete graph connecting those end-hosts, and represent 
paths in the underlying network. Whether communication along those paths 
is multiplexed over tunnels or separated into transport-layer 
connections would be a choice for the designer---with non-trivial 
consequences.  Maybe this is abuse of terminology, but the above 
definition seems to be shared by some. My question was, as you point 
out, about forming overlays without tunnels. The reason to consider this 
an overlay network is that if one has multiple choices of relays, then 
one is faced with a routing problem in addition to a session-splicing 
problem.

/jonathan