Salman, Based on your list, I'm going to assume you agree with the current proposal. RELOAD supports (and prefers) a TCP overlay link protocol, and it offers a UDP-based protocol when that doesn't work. I'd fully support a simple use RFCXXXX for a TCP-over-UDP protocol, but since there isn't one, we have a goal of something that should work, even if it doesn't reach "ideal" (TCP-like) performance. If you believe more needs to be done to specify a real TCP over UDP, I fully support you advancing that in TSV.
Bruce On Thu, Mar 19, 2009 at 12:13 AM, Salman Abdul Baset <[email protected]> wrote: > On Wed, 18 Mar 2009, Bruce Lowekamp wrote: > >> That paper in particular, and the reasons UDP connections are more >> reliably formed than TCP, have been discussed numerous times in >> MMUSIC, and I really don't think we should be repeating the whole >> conversation here. But the summary is that it's not nearly as >> universal a solution as indicated in that paper. >> >> Bruce > > Sure. I have already mentioned that this is a IMC'05 paper and more recent > data, if available, is helpful and needed. > > There are at least four solutions to the hop-by-hop reliability problem: > > (1) Clients > Nodes behind TCP *un*friendly NATs can always act as clients and establish a > TCP connection(s) with reachable node(s). The reachable nodes can be behind > friendly NATs or they can have a public IP address. > > (2) Full peer but use relay peer(s) > A node participates as a peer. It establishes TCP connection with reachable > peers, which inturn establish a TCP connection with the nodes' connection > table entries. > > (3) Full peer with techniques for direct TCP connection establishment > A node participates as a peer and uses TCP traversal techniques for > establishing direct connection (including Dean's upcoming ones:) > > (4) Full peer with TCP-over-UDP > Since TCP traversal may fail, design/reuse a reliable congestion control > protocol over UDP. > > > Note that: > (1) and (2) always work. > > (3) and (4) do not work well behind cascaded NATs. (4) fails behind > UDP-blocking firewalls. > > (4) is feasible over (3) since UDP has a better chance of connection > establishment when NATs are not cascaded. However, UDP blocking firewalls > need to be factored in this feasible discussion. Again, any recent data is > helpful. > > > For (4), the TCP-over-UDP protocol needs to be well-designed and > well-implemented. Otherwise, peers doing TCP-over-UDP may be the weakest > link in the routing chain. Approaches which recover every loss using timeout > may not be the most feasible ones. > > > -salman > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
