Re: [P2PSIP] The case for direct response support in RELOAD

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:bbl@lowekamp.net] 
> Sent: Saturday, November 15, 2008 1:52 PM
> To: Narayanan, Vidya
> Cc: Das, Saumitra; p2psip@ietf.org
> 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 
> <vidyan@qualcomm.com> 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: p2psip-bounces@ietf.org
> >> [mailto:p2psip-bounces@ietf.org] On Behalf Of Das, Saumitra
> >> Sent: Friday, November 14, 2008 1:03 PM
> >> To: p2psip@ietf.org
> >> 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
> >> P2PSIP@ietf.org
> >> https://www.ietf.org/mailman/listinfo/p2psip
> >>
> > _______________________________________________
> > P2PSIP mailing list
> > P2PSIP@ietf.org
> > https://www.ietf.org/mailman/listinfo/p2psip
> >
> 
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip