On Thu, Mar 26, 2009 at 11:53 PM, Salman Abdul Baset <[email protected]> wrote: > >> 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. > There are papers which suggest that a machine can handle thousands of > concurrent TCP connections. > The ability of a machine to handle thousands of mostly idle connections is not really relevant to whether people would participate in an overlay where they wind up consuming half of their broadband link while idle (for example). >>> 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. > > 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. Bruce > > regards, > salman > > >>> -- >>> >>> 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
