On Wed, 18 Mar 2009, Dean Willis wrote:
On Mar 18, 2009, at 7:17 AM, Henning Schulzrinne wrote:
True peers (not clients) behind NATs won't work unless they initiate the
connection anyway, so I'm a bit confused by the model you have in mind.
A signal comes over an existing connection, causing the peer to send UDP out
to a node that can report the address/port number in use. This address/port
set is exchanged with the other peer via the existing connection, then the
peers contact each other directly using the discovered address/ports. Doesn't
work for all NATs, but does for many. And we don't have a trick for doing
that with TCP yet, although I'm working on one.
A related question is what is the percentage of deployed NATs that
support direct TCP connection establishment using techniques such as
Simultaneous-TCP-open?
According to "Characterization and Measurement of TCP Traversal through
NATs and Firewalls", (IMC'05), 88% of the deployed NATs support direct TCP
connection, and 100% for certain common types of NATs. It will be
interesting to see a more recent data on this.
When NATs are cascaded, the direct TCP connections are a problem as
hairpinning support is needed. However, this problem also occurs for
UDP (Section 4, RFC 5128).
The reliability and congestion control discussion for RELOAD revolves
around the notion that direct connection establishment using TCP is orders
of magnitude worse than UDP. It is not clear to me if this is the case,
unless there is data indicating otherwise. It is also not clear to me
whether building a TCP-over-UDP solution will solve the problem of direct
connection establishment, as direct 'connection establishment' over
UDP does not always work.
-salman
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
