Getting direct response to work right in the presence of NATs is monstrously complicated, and its value is not clear (and depends on how complicated the protocol to support it is). B3 of the base draft lists some of the complexities.
Bruce On Sat, Nov 15, 2008 at 8:42 PM, Narayanan, Vidya <[EMAIL PROTECTED]> wrote: > > Actually, the benefits of direct responses are beyond just the scenarios with > absolutely no NATs at all. Large, multi-site enterprises would benefit from > it, as would IPv6 deployments. I was pointing out that even in commercial > environments, there are non-NATed cellular networks. > > Vidya > >> -----Original Message----- >> From: Bruce Lowekamp [mailto:[EMAIL PROTECTED] >> Sent: Saturday, November 15, 2008 1:52 PM >> To: Narayanan, Vidya >> Cc: Das, Saumitra; [email protected] >> Subject: Re: [P2PSIP] The case for direct response support in RELOAD >> >> 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
