- There are still people who want to run UDP between peers. Yes there
are other options for some of those scenarios, but not all. Your
solutions simply don't address all of the problem space. Feel free to
submit a draft proposing to limit the problem space the protocol is
trying to solve.
Perhaps, people who *only* want to run UDP between peers should submit a
seperate draft. It is not something that should be in the base draft when
there are alternate solutions.
It is incorrect to say that my solutions don't address these scenarios.
Establishing TCP connections through mutually reachable peers always work.
Downgrading a node to a client, and establishing a TCP connection with a
reachable peer always work. Again, please see (1) and (2) below. Also,
people are working on techniques for establishing direct TCP connection.
- You have not demonstrated that any of the proposed UDP protocols
have performance inadequate to the requirements of the scenarios in
which they are likely to be needed. Sure they're not up to TCP's
performance. That's not the goal.
I have said it repeatedly that the proposed UDP protocols only recover
losses using *timeouts*. It is well known that recovering losses using
timeouts is a big performance hit. Any TSV person should say this.
- I don't understand why you keep bringing up cascaded NATs. Yes,
it's possible to come up with a NAT/Firewall configuration that will
block any given solution. The point is not that there may exist
systems where a particular solution won't work, it's trying to develop
a solution that solves the vast majority of common cases.
I am curious if you have data indicating that for common cases, TCP
connections don't work and UDP do? You don't agree with the assertions in
the 'Characterizing IMC'05' paper and that's fine. But can you point to
the latest data?
--
I am not religiously against running UDP between peers :). However, based
on reasons stated earlier, I think that RELOAD base draft of the P2PSIP WG
is the *not* right place to insert a reliable congestion control protocol.
It is easy to get these protocols wrong than right. We should not abandon
well designed TCP stacks so easily.
As a practical insight, Skype application will not connect to the Skype
network if it cannot establish a TCP connection with a Skype super node.
For those who want to run UDP, I totally agree with your idea of use
RFC-XXXX for a TCP-over-UDP protocol.
I want to keep our focus on the issues of P2PSIP protocol such as
configuration, security, and overlay maintenance.
Regards,
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
