There are a lot of different definitions of mobile devices. Let's restrict to battery-powered wireless devices for this discussion.
These devices are going to have lower cpu power as well as lower (and shared) bandwidth than comparable wired devices. They also have limited battery power, and most mobile devices users highly value their battery life. Most wireless deployments are not ad-hoc, but have a wired support infrastructure. These restraints lead to two issues: - the wired devices users will see degraded performance when using mobile devices as peers - the mobile device users will not want to run the software if running it drains their battery So in the majority of cases, there is wired infrastructure available that is more appropriate to run peers. Everyone will be happier with better performance and the mobile device users will be happy to run as clients, which doesn't drain their battery by the constant forwarding that is required of peers. Now there are, of course, exceptions. At ietf's we could imagine groups setting up their own overlays on laptops, and ietf has a good enough wireless network and enough power that this would probably work well. A brief coffee house ad hoc network could be set up as an overlay. So there are cases where it will happen. Lots of work has been done on how to use mobile devices in overlay networks, going down to synchronizing clocks on motes in order to minimize the time they have to have their radios listening in order to conserve battery power. These situations tend to be ad hoc networks where you would want to do an unstructured overlay rather than structured to minimize forwarding. And I think it would be great to see someone propose an overlay algorithm (and possibly new timings for other parameters) designed to run reload using mobile devices as peers. But the default overlay algorithm isn't going to be appropriate for mobile devices because it wasn't (and can't be) designed for the right constraints. Bruce On Mon, Nov 17, 2008 at 12:20 AM, Narayanan, Vidya <[EMAIL PROTECTED]> wrote: > > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Eric Rescorla >> Sent: Sunday, November 16, 2008 6:47 AM >> To: Dondeti, Lakshminath >> Cc: [email protected] >> Subject: Re: [P2PSIP] The case for direct response support in RELOAD >> >> At Sat, 15 Nov 2008 16:44:30 -0800, >> Lakshminath Dondeti wrote: >> > >> > 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. >> >> What do you mean "forced"? Being a client is a benefit, not a duty. >> > > Being a client is a benefit to the client itself, but, not necessarily to the > overlay. Being a client is also a local decision. If many devices in the > system actually chose to be clients, that is not a good thing for the system > as a whole. So, we want to incentivize nodes to be peers whenever possible. > > It really makes me uncomfortable when I hear things like designing for a LAN > or flatly dismissing wireless/mobile devices as clients, etc. Not that I'm > saying that any device, no matter what its capabilities are, should be peers. > OTOH, being mindful of the increasing population of wireless and mobile > devices and generally making the system function optimally is a good thing. > > - Vidya > > >> -Ekr >> >> >> _______________________________________________ >> 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
