Hi Bruce,
Responding to a few of your emails in these recent threads:
When considering the "common" use cases, it may be worthwhile to
consider various small, medium and large enterprises where some, many or
most of the employees may be in motion carrying mobile devices either
with them in person or in a truck being part of an overlay. Surely
those devices can't all be forced to be "clients" in all cases. I think
we need to think beyond use cases where all employees in an enterprise
are tethered to their desks. I realize that some consider that normal,
but those bonds are being broken everyday, thankfully :).
Next, if we want to go the route of adding features based on
cost/benefit analysis, we should apply that consistently across the
board. Perhaps we can agree on a framework for modeling and simulations
and justify the current design choices and all future changes based on
simulation results where appropriate. I am actually quite supportive of
that approach.
thanks,
Lakshminath
On 11/15/2008 1:52 PM, Bruce Lowekamp wrote:
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
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
