On Thu, Mar 26, 2009 at 5:36 AM, Salman Abdul Baset <[email protected]> wrote: >> >> 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. >
- 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. - 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 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. Bruce > -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
