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

From: "Das, Saumitra" <[email-masked]>
Date: Fri, 14 Nov 2008 13:03:21 -0800

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-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 14 Nov 2008 15:14:54 -0800

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-masked] 
> [mailto:[email-masked]] On Behalf Of Das, Saumitra
> Sent: Friday, November 14, 2008 1:03 PM
> To: [email-masked]
> 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.
> 
> 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 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

---

From: jiangxingfeng 36340 <[email-masked]>
Date: Sun, 16 Nov 2008 04:11:29 +0800

Hi, Narayanan and Das:

I agree with you guys. I also think relay peer routing mode also be helpful in wireless situation, by considering in China most mobile devices gets NATed because of depletion of global IPv4 address. 

In http://tools.ietf.org/id/draft-jiang-p2psip-relay-00.txt, we prposes an extension to make the direct response and relay peer available in RELOAD. So I think these two additional routing modes will be helpful in certain situations. The draft provides avaiable tools to support them and it depends on the peer to decide which will be used. For example, it can based on past experience on different routing modes, such as, symmetric recursive, 
diret response or relay peer, to decide which one will be used first. The peer also use ping or some other messages to perodically to try different routing modes to get the success rate of the respective routing mode and make the determination. 

Regards
Jiang XingFeng

> 
> 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 
>

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Sat, 15 Nov 2008 16:52:17 -0500

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 15 Nov 2008 16:44:30 -0800

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:
> 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.
> 
> 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.
> 
> 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.
> 
>> 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).
>> 
>>> -----Original Message----- From: [email-masked] 
>>> [mailto:[email-masked]] On Behalf Of Das, Saumitra Sent:
>>> Friday, November 14, 2008 1:03 PM To: [email-masked] 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.
>>> 
>>> 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.
>>> 
>>> Thanks Saumitra _______________________________________________ 
>>> P2PSIP mailing list [email-masked] 
>> _______________________________________________ P2PSIP mailing list
>>  [email-masked] https://www.ietf.org/mailman/listinfo/p2psip
>> 
> _______________________________________________ P2PSIP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/p2psip
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sat, 15 Nov 2008 17:42:55 -0800

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

> From: Bruce Lowekamp [mailto:[email-masked]] 
> Sent: Saturday, November 15, 2008 1:52 PM
> To: Narayanan, Vidya
> Cc: Das, Saumitra; [email-masked]
> Subject: Re: [P2PSIP] The case for direct response support in RELOAD
> 
> 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.
> 
> 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
> 
> 
> > 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
> >
> >> advantages 1. The latency of a transaction is reduced.
> 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.
> >>
> >> 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.
> >>
> >> Shenker. Fixing the Embarrassing Slowness of OpenDHT on PlanetLab. 
> >> Proceedings of USENIX WORLDS 2005, December 2005.
> >>
> >> Thanks
> >> Saumitra

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Sat, 15 Nov 2008 20:57:34 -0500

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 16 Nov 2008 08:46:36 -0600

At Sat, 15 Nov 2008 16:44:30 -0800,
Lakshminath Dondeti wrote:
> 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.

-Ekr

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 16 Nov 2008 21:20:45 -0800

> [mailto:[email-masked]] On Behalf Of Eric Rescorla
> Sent: Sunday, November 16, 2008 6:47 AM
> To: Dondeti, Lakshminath
> Cc: [email-masked]
> > 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Nov 2008 08:58:05 -0600

At Sun, 16 Nov 2008 21:20:45 -0800,
Narayanan, Vidya wrote:
> Being a client is a benefit to the client itself, but, not
> necessarily to the overlay.

Not necessarily, but sometimes. If I have a cray behind a
2400 bps modem, it's not a benefit for the overlay for it to 
be a client.

> 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. 

Again, that's not clear. It depends on the properties of those
nodes.

> 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.

I don't think that people are doing that. Rather, I think that
people are questioning whether it's important to have devices
with extremely limited capabilities be able to act as peers.

-Ekr

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Mon, 17 Nov 2008 11:41:19 -0500

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 17 Nov 2008 12:30:16 -0800

> 
> I don't think that people are doing that. Rather, I think 
> that people are questioning whether it's important to have 
> devices with extremely limited capabilities be able to act as peers.
> 

Let's define "extremely limited capabilities" for everyone's benefit here.  In my view, an unplugged laptop on a wireless link does not fit that definition, but, following some of the other emails here, it looks like some might put such laptops into this category.  OTOH, a wireless audio out device similar to a Bluetooth headset does fit that category.  Cellular phones vary widely in capabilities - they cannot all be taken as low capability devices.  High range phones are more comparable to low range PCs.  The mid-range phones are probably somewhere in between - depending on the overlay and their connectivity and power conditions, they may have limited capabilities or enough to function as a peer.  

It'll be good to know what everyone else means by "extremely limited capabilities" so that we don't keep talking past each other. 

- Vidya

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Nov 2008 14:54:58 -0600

At Mon, 17 Nov 2008 12:30:16 -0800,
Narayanan, Vidya wrote:
> Let's define "extremely limited capabilities" for everyone's benefit
> here.  In my view, an unplugged laptop on a wireless link does not
> fit that definition, but, following some of the other emails here,
> it looks like some might put such laptops into this category.  OTOH,
> a wireless audio out device similar to a Bluetooth headset does fit
> that category.  Cellular phones vary widely in capabilities - they
> cannot all be taken as low capability devices.  High range phones
> are more comparable to low range PCs.  The mid-range phones are
> probably somewhere in between - depending on the overlay and their
> connectivity and power conditions, they may have limited
> capabilities or enough to function as a peer.

I mostly agree with this classification.

-Ekr