It's certainly true that many of the arguments against direct responses go away if you can assume your deployment has no NATs. It's also completely true that there are such deployments, although I doubt they would be the majority.
One of the issues that needs to be addressed when comparing the efficiency of direct response is to include the cost of negotiating tcp and/or tls before sending any actual data. The cost of that is non-trivial, so comparing them is not quite as simple as counting the direct response as 1 hop. 3 symmetric response hops may well be faster than opening a new TCP/TLS connection for sending the response. Again, there are deployments where this isn't an issue and you can just send a single UDP packet, but I don't think they're the majority. I would be very interested in seeing an analysis of the cost/benefit of using mobile wireless devices as peers compared to using the mobile devices as clients and using the APs as peers. Not saying there's not an argument or occasion for doing it, I'm just not convinced it's going to be very common. Given all the limitations of when direct response is clearly beneficial, I'm still opposed to having it as part of the base protocol. I do want to see it as an extension, however. Bruce On Fri, Nov 14, 2008 at 6:14 PM, Narayanan, Vidya <[EMAIL PROTECTED]> wrote: > > Direct routing has huge benefits in the presence of wireless devices. The > current routing choices assume that we need symmetric routing to handle NATs > and hence, that is the common case. It turns out that there are several > cellular networks today that are non-NATed (shocking, but, true for now, at > least in the US). So, it would be bad to not take advantage of that for > improving the lookup latency. Worse still, by forcing symmetric routing all > the time, we would have cut the budget for the maximum number of wireless > hops in one direction to half (with only 3-4 wireless hops budgeted for the > entire lookup to have an acceptable call setup latency, this makes it > significantly worse). > > So, we really should make direct routing part of the base spec if we want > RELOAD working well with wireless devices. > > Vidya > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Das, Saumitra >> Sent: Friday, November 14, 2008 1:03 PM >> To: [email protected] >> Subject: [P2PSIP] The case for direct response support in RELOAD >> >> Hi all, >> >> I think we should consider a direct reponse based >> asymmetric routing as part of the base draft in RELOAD. There >> are several advantages 1. The latency of a transaction is reduced. >> 2. Given the increasing spread of mobile devices that may >> participate in such overlays direct response routing can >> reduce the resource usage on multiple wireless hops. >> 3. Many hosts (such as in mobile broadband networks) are not >> always behind NATs and in such cases direct response routing >> is even more beneficial as we do not need to perform ICE. >> >> Another draft (ref 1) also supports this view. >> >> openDHT also seems to support such as mode of operation (see >> Ref 2). While it mainly operates on a testbed with public >> Ips, one can make the case that there may be many such nodes >> in a deployed RELOAD overlay. E.g. university machines, >> wireless hosts etc. >> >> Ref 1: http://tools.ietf.org/id/draft-jiang-p2psip-relay-00.txt >> Ref 2: Sean Rhea, Byung-Gon Chun, John Kubiatowicz, and Scott >> Shenker. Fixing the Embarrassing Slowness of OpenDHT on >> PlanetLab. Proceedings of USENIX WORLDS 2005, December 2005. >> >> Thanks >> Saumitra >> _______________________________________________ >> 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
