On Fri, Mar 27, 2009 at 8:41 AM, 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. > > 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? >
The charter says: "The working group will assume that NATs and firewalls exist in the Internet, and will ensure that the protocols produced work in their presence as much as possible." I interpret that to mean that we should support UDP, and as long as we do so within the framework of RFC5405, which specifies guidelines for congestion control, reliability, etc., we are doing what our charter and usage scenarios require in compatibility with TSV's current view on the requirements. > >>>>> 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? > Depends on how many fragments the typical message has, and how long the reassembly buffer is preserved on the receiver to receive the retransmission. Obviously this was a major problem for early poor ATM implementations. Going back a bit, my initial argument was that each hop should do reassembly. Numerous other people on the mailing list argued that this was too expensive, and that we should adopt a simpler approach. I tried to balance performance and simplicity in the more recent email. But there are a lot of different perspectives on what the most important features to be optimized are. I certainly consider whether such overlay link protocols must include behaviors such as dupack loss detection and fragment/message dropping to be open issues. > > >>> 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. > keep-alives have to be run over the same channel as the main messages. (keep-alives in the NAT/firewall maintenance sense, you're right that a peer liveness check could run in a different flow.) Bruce > 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
