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
