[e2e] overlay over TCP

[Jonathan Shapiro]

In terms of preserving TCP friendliness, would TCP flow control provide 
a natural form back pressure for TCP sessions coupled  together in 
sequence and thus constrain the rate of a session over the VC to the 
minimum available bandwidth on any individual overlay link?

There's been some work on this back pressure mechanism for 
application-level multicast. The following links might be helpful
http://www.cs.bu.edu/techreports/pdf/2003-015-roma.pdf
http://www.eurecom.fr/~btroup/BPublished/ngc2002_overlay.pdf
http://www-lor.int-evry.fr/~templemo/Academic/REALM/realm.html
http://www.eecg.toronto.edu/~bli/papers/jsac04.pdf
http://www.cs.cornell.edu/home/rvr/papers/SelectCast.ps
http://www.arl.wustl.edu/Publications/2000-04/wucs0017.pdf

When you say "avoid some of the application-layer problems of reliable 
in-order delivery" are you thinking about multiplexing many logical 
sessions over a single TCP VC? In that case, would a protocol like SCTP 
be a reasonable alternative to TCP?

/jonathan

David P. Reed wrote:

> Anyone know of any experiments that have involved overlay networks 
> that run over TCP virtual circuits, but which try to avoid some of the 
> application-layer problems of reliable in-order delivery?
>
> I'm interested in optimizing any end-to-end goal-function other than 
> bulk transfer speed.  (yeah, I know about a lot of the research and 
> hacking that uses multiple TCP connections to blast a file from here 
> to there).
>
> Ideally, I'm interested in approaches that focus on preserving 
> TCP-friendliness (and generally would be seen as cooperative in 
> sharing the network resources rather than greedy or dangerous).
>
> Obviously I'm interested because I've begun playing around with such 
> ideas.  They might be practically useful in a world where UDP is 
> viewed as a "security hole," but TCP is not (I don't agree, but why 
> fight stupid people if you don't have to).  Don't want to reinvent the 
> wheel.