Salman
Simply refusing to admit that use cases exist where TCP can't be used
between all peers does not make them go away.
Bruce
I think I have been pretty clear that there are scenarios where TCP cannot
be used; however, it is still an open question whether they are dominant
ones, and if they are, an adhoc approach with poor performance is not
the answer. Further, direct connections for both UDP and TCP do not work
for cascaded NATs.
I have earlier outlined solutions for scenarios where TCP cannot be used
(see 1-3 below) that do not require a TCP-over-UDP or a similar approach.
They are a full peer with connections established over TCP through a relay
peer, developing techniques for direct TCP connection establishment (in
BEHAVE WG), or downgrading a peer to a client.
-salman
(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
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
