On Thu, Mar 26, 2009 at 4:10 PM, Salman Abdul Baset <[email protected]> wrote: > >> - 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. >
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. > >> - 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. > 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 - Having timeout based retransmission was purely a way of simplifying the protocols to be easier to implement (correctly) - Once again, the goal isn't to achieve equal performance to TCP. The goal is to provide sufficient performance and not destroy the Internet - If you read the TFRC spec, it includes dupack calculation, which can be used to determine loss. The receiver algorithm was simplified a little bit to make this impossible, and I see the value of that simplification as more important than the lost performance, given that this isn't a stream-based protocol in the first place. The difference between an ideal overlay link protocol and a stream-based protocol (such as how the TFRC version only retransmits an individual fragment twice) is actually an important point to keep in mind, and probably means that TCP over UDP is not actually the ideal protocol. (But I don't necessarily believe it would be worthwhile to work out an appropriate spec to that level of detail. I think it's more important to have easily implementable protocols that work, and would prefer a TCP over UDP that can be included by reference.) > >> - 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? > Once again, I don't believe it's worth rehashing years of conversation in MMUSIC here. But if nothing else, observe that ICE-UDP is a lot further along (finished) than ICE-TCP (trying to get restarted). Bruce > -- > > 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
