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
