Your alternate solution is an assumption that the overlay will contain
enough TCP open-access nodes that are able to identify themselves as
open-access nodes and willing to bear the burden of their role on
behalf of all the other peers. What I've seen is that UDP actually
works, and TCP doesn't.
Skype works. It has enough nodes that can provide relay services.
Once again, I'm not saying your scenario doesn't exist. I'm just
saying that there are other scenarios.
Sure there are other scenarios, but the justification for including your
TCP-over-UDP solutions in the base protocol has to be based on solid data,
whether they are the *only* viable option, whether they have any
performance issues, and whether P2PSIP WG is the right place for them.
You have agreed in the earlier posts that there are scenarios where direct
connections are not possible. Maybe, RELOAD should not be run in those
scenarios, right?
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.
This is a bit of an oversimplification.
- it's not a stream based protocol. So a timeout of one fragment
doesn't have any affect on the others, like it does in TCP
You are missing inorder delivery here. Unless the lost fragment is
retransmitted and received, all the other segments in the receive buffer are
useless.
No, I'm not missing it, I'm deliberately excluding it. That's not a
service the Internet guarantees, and the complexities required to
guarantee it on an overlay network are too high.
Unless a packet is deemed loss using a *timeout*, and retransmitted, and
received at the receive buffer, all other packets are useless. Isn't this
a big performance hit?
I think the following questions should be discussed in the WG meeting.
1) Is designing a reliable congestion protocol within scope of P2PSIP WG?
2) If yes,
a) shall it be specified in the base document?
b) what should be its performance if a large number of peers were to run
it?
c) what is the impact on routing performance?
It's a semi-reliable congestion control protocol, but yes, that's a
perfectly good topic for the wg to consider. However, so far I'm not
aware of anyone but you who believes we should exclude UDP from the
protocol.
It is a jump in the thought to say that I am excluding UDP. I am not. UDP
is perfectly suitable for messages that do not exceed MTU such as
keep-alives.
I will let WG discuss these questions :)
-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
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
