Subject: Re: [P2PSIP] do we need a client protocol?

From: "Wei Gengyu" <[email-masked]>
Date: Thu, 28 Jun 2007 10:49:57 +0800

Hi, 

A cell phone have full receiving capabilities in standby mode.
The cell phone will enter the active mode (you said "talk" mode) 
after receiving a paging frame containing "setup" message destined to it. 

In standby mode, it can listen any messages of signalling and/or IP packets.
So, yes it is possible to have a phone in low-power standby mode but (for example) listening for incoming TCP connections or UDP packets.

However, the power consumption to send messages is mostly converned when the cell phone is in active mode. 

But, I do not think this should be dominate P2PSIP overlay design in this stage.

Gengyu
  ----- Original Message ----- 
  From: David Barrett 
  To: 'Henry Sinnreich' ; [email-masked] ; [email-masked] ; [email-masked] 
  Cc: [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Thursday, June 28, 2007 6:41 AM
  Subject: RE: [P2PSIP] do we need a client protocol?

  That makes sense.  So my next question is: what are the capabilities of standby mode, and what triggers it going into "talk" mode?

  It must be listening to some sort of cell signal even in standby mode, just so it can receive phone calls.  Given this, when in standby mode, does it also have access to the IP network?  In other words, is it possible to have a phone in low-power standby mode but (for example) listening for incoming TCP connections or UDP packets?

  -david

------------------------------------------------------------------------------

  From: Henry Sinnreich [mailto:[email-masked]] 
  Sent: Wednesday, June 27, 2007 1:39 PM
  To: David Barrett; [email-masked]; [email-masked]; [email-masked]
  Cc: [email-masked]; [email-masked]; [email-masked]
  Subject: RE: [P2PSIP] do we need a client protocol?

  It is more complicated than this.

  Under normal cell phone operation we have the talk time and the standby time which is much longer.

  Making a cell phone a full peer eliminates this distinction to a large degree since the overlay maintenance messages keep the phone 'talking' all the time.

  Henry

------------------------------------------------------------------------------

  From: David Barrett [mailto:[email-masked]] 
  Sent: Wednesday, June 27, 2007 10:06 AM
  To: [email-masked]; [email-masked]; [email-masked]
  Cc: Henry Sinnreich; [email-masked]; [email-masked]; [email-masked]
  Subject: RE: [P2PSIP] do we need a client protocol?

  I don't know anything about mobile application design vis-à-vis battery life, but I'm guessing power usage could be vastly oversimplified to something like:

  Power = A + nB

  Where A is the overall cost of just having the device powered on and listening to the radio, and B is the cost of sending a byte of data.  What I'm wondering is, what is the ratio of A to B?  Can anyone give real-world data?

  For example, I'd accept that sending 200Mbps probably requires about 2x the power 100Mbps: for a high enough value of 'n', then the constant A gets marginalized.  But what about 200Kbps or 200bps?  For some low value of 'n', then A dominates the power usage.

  The reason I ask is I wonder if it's even useful to discuss power usage for something like P2PSIP.  It could be that even for a "real" peer, 'n' is so low that the power consumption is dominated by other factors, rendering the entire discussion moot.

  Can anybody give real-world data on this topic?

  -david 

------------------------------------------------------------------------------

  From: [email-masked] [mailto:[email-masked]] 
  Sent: Wednesday, June 27, 2007 12:33 AM
  To: [email-masked]; [email-masked]
  Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
  Subject: RE: [P2PSIP] do we need a client protocol?

  Hi,

  We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's N-series/E-series devices are very powerful. From this reason some of mobile terminals may become peers (depending on the case scenario: churn, size of the network). However there are also many entry-level/low-end devices that have slow CPUs and limited memory. 

  Battery life is another issue. Most of the mobile phone users want long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the active state (e.g. when user is calling/answering a call).

  I was considering a similar solution to the one that Alan proposed however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We also have problems with handling searches.

  I assume that we will have some mobile terminals taking part in DHT and some accessing resources stored in DHT using a client protocol.

  Marcin

----------------------------------------------------------------------------

    From: ext Eunsoo Shim [mailto:[email-masked]] 
    Sent: 27 June, 2007 02:26
    To: Alan Johnston
    Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing List
    Subject: Re: [P2PSIP] do we need a client protocol?

    On 6/26/07, Alan Johnston <[email-masked]> wrote: 

    I've been giving this a lot of thought lately, thinking about the actual
    requirements.

    We want to allow energy-limited devices to participate to some level in
    P2PSIP.   As such, perhaps instead of saying we need a client protocol, 
    perhaps we just need levels of participation in the overlay peer protocol.

    For example, a normal peer in the overlay will maintain peer protocol
    connections with many (perhaps dozens) of peers.  Why?  So that it can 
    quickly and efficiently route requests within the overlay.

      Perhaps an energy-limited device could just minimize the number of peer
      protocol connections it maintains, perhaps even down to a minimum of
      two.  This would result in slower routing of its requests through the
      overlay, but that seems like a reasonable tradeoff. 

    The underling algorithm (e.g. a certain DHT algorithm) will dictate the number of connections even though there might be some room for adjustment. I don't think it is under complete control of individual peer in the case of known DHT algorithms. 

      Also, perhaps there are some other peer protocol functions, such as data
      replication (storage would still be done, but not replication), that 
      could be skipped by these energy-limited peers.  Perhaps their requests
      and responses could be routed over the overlay with a lower priority
      than full peers.  We need to manage the tradeoffs so that those peers
      who contribute the least to the overlay also get the lowest performance
      from it.

    I am not quite sure I understand the benefit of introducing such various levels of participation.
    Having a client protocol seems to be much simpler and easier than introducing these various levels of participation. 

    Thanks.

    Eunsoo

      Henry Sinnreich wrote:
      > Folks,
      > 
      > Given the length of the discussion on "do we need a client protocol?"
      > let me repeat the simple imperatives for the client:
      >
      > - Limited battery in mobile devices, and
      >
      > - Other uses besides SIP. Business planning folks may not care about the 
      > WG charter, but about the return on the investment.
      >
      > Thanks, Henry
      >
      > -----Original Message-----
      > From: Dean Willis [mailto:[email-masked] ]
      > Sent: Thursday, June 14, 2007 11:23 PM
      > To: David A. Bryan
      > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
      > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive 
      > peerterminology
      >
      > David A. Bryan wrote:
      >
      >> If I understand this right, not sure I like it. Do these
      >>
      > "non-contributing
      >
      >> peer" (I *do* like contributing better than active/passive) entities 
      >>
      > have a
      >
      >> Peer-ID? In otherwords, are they part of the overlay at all? If so,
      >>
      > for
      >
      >> most
      >> DHTs, how do we allow you to be in the overlay and not store resources 
      >>
      > (not
      >
      >> typical for most current DHT algorithms)
      >>
      >
      > Well, that certainly depends on the DHT algorithm involved. It certainly
      > seems that a peer that moves between contributing and non-contributing 
      > might HAVE a peer ID, but whether it chooses to insert itself into the
      > DHT "right now" might determine whether it is contributing "right now"
      > or not.
      >
      >
      >> My concern all along has been that I don't understand why something 
      >> is a peer if it isn't doing anything other than talking to someone
      >> and making requests, hence why I supported client in the first place.
      >>  I fail to see how something that isn't contributing anything, and 
      >> instead talks to a peer to get resources, is in any way a peer. It
      >> seems completely not in keeping with the idea of P2P. I also worry it
      >>  is likely to be very confusing since we've been using the other 
      >> terminology for over a year now. Just looks like a souce of confusion.
      >>
      >
      > A node might sometimes have a high-bandwidth connection and wish to
      > contribute resources, and sometimes not have a high-bandwidth connection 
      > and therefore not wish to offer resources. Does this modality make it
      > two different nodes?
      >
      >
      >> If we do go this way, there is one subtle point. If I join the overlay
      >>
      > but
      >
      >> don't happen to offer any services (other than maybe
      >>
      > storage...depending on
      >
      >> how we definie it, that might or might not be mandatory), would I be
      >> contributing? If joining the overlay (in the sense that we have a
      >>
      > PeerID
      >
      >> and
      >> we route traffic) doesn't require me to store, I could offer no
      >>
      > services
      >
      > That's "offer no other services", since routing is itself a service.
      >
      >
      >> and
      >> still be a peer. How do we distinguish between this case and a
      >> "non-contributing peer" who isn't even part of the overlay (i.e., no
      >> Peer-ID)
      >>
      >
      > I think there's a range of "contributing" in play. For most DHT models, 
      > a minimally contributing node will route a request it receives. It might
      > ask nicely (perhaps a q-value mechanism) to not have to route requests,
      > but would probably mathematically still have to route something it gets. 
      >
      > I think we distinguish based on the service advertisements from the
      > peer.
      >
      >
      >> If we are so opposed to client for confusion with SIP UAs, lets pick a
      >>
      > new 
      >
      >> name, but why some flavor of peer when it does nothing remotely peer
      >>
      > like?
      >
      > Because in 15 minutes it might roam onto a WiFi net and therefore change
      > it service offering. 
      >
      > --
      > Dean
      >
      > _______________________________________________
      > P2PSIP mailing list
      > [email-masked]
      > https://www1.ietf.org/mailman/listinfo/p2psip
      >
      > _______________________________________________
      > P2PSIP mailing list
      > [email-masked]
      > https://www1.ietf.org/mailman/listinfo/p2psip
      >
      >
      >

      _______________________________________________
      P2PSIP mailing list
      [email-masked]
      https://www1.ietf.org/mailman/listinfo/p2psip

------------------------------------------------------------------------------

  _______________________________________________
  P2PSIP mailing list
  [email-masked]
  https://www1.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Greger V. Teigre" <[email-masked]>
Date: Thu, 28 Jun 2007 08:15:12 +0200

Well, it's a bit more complicated than that. For one thing, there's a 
difference between mobile and WLAN. Even with the power-saving mode of 
802.11g for example, there's still more power drain when connected to 
WLAN, than mobile. And on mobile, you have many scenarios, just take the 
GSM (which I know the best), you have GSM High-Speed, still used by many 
roadwarriors in many areas of the world, and you have GPRS/EDGE/3G data 
connections. You can have three modes, each with different power 
consumption: No connection (only voice), PDP context established, and 
active connection. Real-life experimentation with various modes and 
applications using these modes show that battery drainage is a real 
problem.
As an example: a native Symbian application that looks up incoming calls 
(over 3G data connection) where caller-id is not found in the local 
contact list needs to have an active connection (not only PDP context), 
because in order to show the caller's data, the lookup must be almost 
instantaneous. In reality, it takes about 1 second.  This application is 
pretty much useless if you actually make any calls, because at the end 
of the day, you don't have battery left...
BTW, the same holds for innovative mobile VoIP apps such as Fling.

For a mobile unit to be a peer, we need a battery revolution.
g-)

Wei Gengyu wrote:
> So, yes it is possible to have a phone in low-power standby mode but 
> (for example) listening for incoming TCP connections or UDP packets.
>  
> *But, I do not think this should be dominate P2PSIP overlay design in 
> this stage.*
>  
>  
> Gengyu
>
>     *From:* David Barrett <mailto:[email-masked]>
>     *To:* 'Henry Sinnreich' <mailto:[email-masked]> ;
>     [email-masked] <mailto:[email-masked]>
>     ; [email-masked] <mailto:[email-masked]> ;
>     [email-masked] <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]> ;
>     [email-masked] <mailto:[email-masked]> ;
>     [email-masked] <mailto:[email-masked]>
>     *Sent:* Thursday, June 28, 2007 6:41 AM
>     *Subject:* RE: [P2PSIP] do we need a client protocol?
>
>     That makes sense.  So my next question is: what are the
>     capabilities of standby mode, and what triggers it going into
>     "talk" mode?
>
>      
>
>     It must be listening to some sort of cell signal even in standby
>     mode, just so it can receive phone calls.  Given this, when in
>     standby mode, does it also have access to the IP network?  In
>     other words, is it possible to have a phone in low-power standby
>     mode but (for example) listening for incoming TCP connections or
>     UDP packets?
>
>      
>
>     -david
>
>      
>
>     ------------------------------------------------------------------------
>
>     *From:* Henry Sinnreich [mailto:[email-masked]]
>     *Sent:* Wednesday, June 27, 2007 1:39 PM
>     *To:* David Barrett; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>     *Subject:* RE: [P2PSIP] do we need a client protocol?
>
>      
>
>     Making a cell phone a full peer eliminates this distinction to a
>     large degree since the overlay maintenance messages keep the phone
>     'talking' all the time.
>
>      
>
>     Henry
>
>      
>
>     ------------------------------------------------------------------------
>
>     *From:* David Barrett [mailto:[email-masked]]
>     *Sent:* Wednesday, June 27, 2007 10:06 AM
>     *To:* [email-masked]; [email-masked];
>     [email-masked]
>     *Cc:* Henry Sinnreich; [email-masked];
>     [email-masked]; [email-masked]
>     *Subject:* RE: [P2PSIP] do we need a client protocol?
>
>      
>
>     I don't know anything about mobile application design vis-à-vis
>     battery life, but I'm guessing power usage could be vastly
>     oversimplified to something like:
>
>      
>
>     Power = A + nB
>
>      
>
>     Where A is the overall cost of just having the device powered on
>     and listening to the radio, and B is the cost of sending a byte of
>     data.  What I'm wondering is, what is the ratio of A to B?  Can
>     anyone give real-world data?
>
>      
>
>     For example, I'd accept that sending 200Mbps probably requires
>     about 2x the power 100Mbps: for a high enough value of 'n', then
>     the constant A gets marginalized.  But what about 200Kbps or
>     200bps?  For some low value of 'n', then A dominates the power usage.
>
>      
>
>     The reason I ask is I wonder if it's even useful to discuss power
>     usage for something like P2PSIP.  It could be that even for a
>     "real" peer, 'n' is so low that the power consumption is dominated
>     by other factors, rendering the entire discussion moot.
>
>      
>
>     ------------------------------------------------------------------------
>
>     *From:* [email-masked]
>     [mailto:[email-masked]]
>     *Sent:* Wednesday, June 27, 2007 12:33 AM
>     *To:* [email-masked]; [email-masked]
>     *Cc:* [email-masked]; [email-masked];
>     [email-masked]; [email-masked]
>     *Subject:* RE: [P2PSIP] do we need a client protocol?
>
>      
>
>     Hi,
>
>      
>
>     We have wide variety of mobile terminals. The capabilities of
>     mobile terminals are constantly improving e.g. even now Nokia's
>     N-series/E-series devices are very powerful. From this reason some
>     of mobile terminals may become peers (depending on the case
>     scenario: churn, size of the network). However there are
>     also many entry-level/low-end devices that have slow CPUs
>     and limited memory. 
>
>     Battery life is another issue. Most of the mobile phone users want
>     long battery life. DHT maintenance and handling searches have
>     impact on idle state that is more important from battery life
>     perspective than the active state (e.g. when user is
>     calling/answering a call).
>
>         
>
>     I was considering a similar solution to the one that Alan proposed
>     however as Eunsoo said it would be quite difficult to control the
>     number of connections in DHT. We also have problems with handling
>     searches.
>
>      
>
>     I assume that we will have some mobile terminals taking part in
>     DHT and some accessing resources stored in DHT using a client
>     protocol.
>
>
>     Marcin
>
>         ------------------------------------------------------------------------
>
>         *From:* ext Eunsoo Shim [mailto:[email-masked]]
>         *Sent:* 27 June, 2007 02:26
>         *To:* Alan Johnston
>         *Cc:* Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP
>         Mailing List
>         *Subject:* Re: [P2PSIP] do we need a client protocol?
>
>          
>
>         On 6/26/07, *Alan Johnston* <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>         The underling algorithm (e.g. a certain DHT algorithm) will
>         dictate the number of connections even though there might be
>         some room for adjustment. I don't think it is under complete
>         control of individual peer in the case of known DHT algorithms.
>
>              
>
>         Having a client protocol seems to be much simpler and easier
>         than introducing these various levels of participation.
>
>         Thanks.
>
>         Eunsoo
>
>              
>
>             Henry Sinnreich wrote:
>             > Folks,
>             >
>             > From: Dean Willis [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             > [email-masked] <mailto:[email-masked]>
>             > [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>     ------------------------------------------------------------------------
> ------------------------------------------------------------------------
>

---

From: <[email-masked]>
Date: Thu, 28 Jun 2007 15:12:22 +0300

Hi Greger,
 
I agree with you that most of mobile terminals that are available on the market cannot became peers. Actually it is not black and white they can but everything depends on the size of a P2P network, used DHT and a traffic model. We must remember that the standard will be ready in a couple of years when we may have more devices that are peer capable. 
 
Marcin 

________________________________

	From: ext Greger V. Teigre [mailto:[email-masked]] 
	Sent: 28 June, 2007 09:15
	To: Wei Gengyu
	Cc: [email-masked]
	Subject: Re: [P2PSIP] do we need a client protocol?

	Well, it's a bit more complicated than that. For one thing, there's a difference between mobile and WLAN. Even with the power-saving mode of 802.11g for example, there's still more power drain when connected to WLAN, than mobile. And on mobile, you have many scenarios, just take the GSM (which I know the best), you have GSM High-Speed, still used by many roadwarriors in many areas of the world, and you have GPRS/EDGE/3G data connections. You can have three modes, each with different power consumption: No connection (only voice), PDP context established, and active connection. Real-life experimentation with various modes and applications using these modes show that battery drainage is a real problem. 
	As an example: a native Symbian application that looks up incoming calls (over 3G data connection) where caller-id is not found in the local contact list needs to have an active connection (not only PDP context), because in order to show the caller's data, the lookup must be almost instantaneous. In reality, it takes about 1 second.  This application is pretty much useless if you actually make any calls, because at the end of the day, you don't have battery left...
	BTW, the same holds for innovative mobile VoIP apps such as Fling.

	Wei Gengyu wrote: 

		Hi, 

		 

		Gengyu

			----- Original Message ----- 
			From: David Barrett <mailto:[email-masked]>  
			To: 'Henry Sinnreich' <mailto:[email-masked]>  ; [email-masked] ; [email-masked] ; [email-masked] 
			Cc: [email-masked] ; [email-masked] ; [email-masked] 
			Sent: Thursday, June 28, 2007 6:41 AM
			Subject: RE: [P2PSIP] do we need a client protocol?

			-david

________________________________

			Henry

________________________________

			Power = A + nB

			-david 

________________________________

			Hi,

			Marcin

________________________________

				

					

				
				
				Thanks.
				
				Eunsoo

			

________________________________

		
________________________________

---

From: "Greger V. Teigre" <[email-masked]>
Date: Thu, 28 Jun 2007 14:19:48 +0200

Hi Marcin,
Yes, I have a fairly practical (and pessimistic) point of view. Nothing 
I have seen of developments indicate that the battery squeeze will be 
over any time soon. Looking back a couple of years, I see mobile phones 
having far longer standby times than today (remember the 6210/6310 ;-) 
The trajectory of battery capacity does not seem to improve any time soon.
Of course, there may be things you know that I don't ;-) Maybe you want 
to share?!
g-)

[email-masked] wrote:
> Hi Greger,
>  
> I agree with you that most of mobile terminals that are available on 
> the market cannot became peers. Actually it is not black and 
> white they can but everything depends on the size of a P2P network, 
> used DHT and a traffic model. We must remember that the standard will 
> be ready in a couple of years when we may have more devices that are 
> peer capable.
>  
> Marcin 
>
>     *From:* ext Greger V. Teigre [mailto:[email-masked]]
>     *Sent:* 28 June, 2007 09:15
>     *To:* Wei Gengyu
>     *Cc:* [email-masked]
>     Well, it's a bit more complicated than that. For one thing,
>     there's a difference between mobile and WLAN. Even with the
>     power-saving mode of 802.11g for example, there's still more power
>     drain when connected to WLAN, than mobile. And on mobile, you have
>     many scenarios, just take the GSM (which I know the best), you
>     have GSM High-Speed, still used by many roadwarriors in many areas
>     of the world, and you have GPRS/EDGE/3G data connections. You can
>     have three modes, each with different power consumption: No
>     connection (only voice), PDP context established, and active
>     connection. Real-life experimentation with various modes and
>     applications using these modes show that battery drainage is a
>     real problem.
>     As an example: a native Symbian application that looks up incoming
>     calls (over 3G data connection) where caller-id is not found in
>     the local contact list needs to have an active connection (not
>     only PDP context), because in order to show the caller's data, the
>     lookup must be almost instantaneous. In reality, it takes about 1
>     second.  This application is pretty much useless if you actually
>     make any calls, because at the end of the day, you don't have
>     battery left...
>>     So, yes it is possible to have a phone in low-power standby mode
>>     but (for example) listening for incoming TCP connections or UDP
>>     packets.
>>      
>>     However, the power consumption to send messages is mostly
>>     converned when the cell phone is in active mode.
>>      
>>     *But, I do not think this should be dominate P2PSIP overlay
>>     design in this stage.*
>>      
>>      
>>     Gengyu
>>
>>         [email-masked]
>>         <mailto:[email-masked]> ; [email-masked]
>>         <mailto:[email-masked]> ; [email-masked]
>>         It must be listening to some sort of cell signal even in
>>         standby mode, just so it can receive phone calls.  Given
>>         this, when in standby mode, does it also have access to the
>>         IP network?  In other words, is it possible to have a phone
>>         in low-power standby mode but (for example) listening for
>>         incoming TCP connections or UDP packets?
>>
>>         -david
>>
>>         Making a cell phone a full peer eliminates this distinction
>>         to a large degree since the overlay maintenance messages keep
>>         the phone 'talking' all the time.
>>
>>         Henry
>>
>>         I don't know anything about mobile application design
>>         vis-à-vis battery life, but I'm guessing power usage could be
>>         vastly oversimplified to something like:
>>
>>         Power = A + nB
>>
>>         Where A is the overall cost of just having the device powered
>>         on and listening to the radio, and B is the cost of sending a
>>         byte of data.  What I'm wondering is, what is the ratio of A
>>         to B?  Can anyone give real-world data?
>>
>>         For example, I'd accept that sending 200Mbps probably
>>         requires about 2x the power 100Mbps: for a high enough value
>>         of 'n', then the constant A gets marginalized.  But what
>>         about 200Kbps or 200bps?  For some low value of 'n', then A
>>         dominates the power usage.
>>
>>         The reason I ask is I wonder if it's even useful to discuss
>>         power usage for something like P2PSIP.  It could be that even
>>         for a "real" peer, 'n' is so low that the power consumption
>>         is dominated by other factors, rendering the entire
>>         discussion moot.
>>
>>         mobile terminals are constantly improving e.g. even
>>         now Nokia's N-series/E-series devices are very powerful. From
>>         this reason some of mobile terminals may become peers
>>         (depending on the case scenario: churn, size of the
>>         network). However there are also many entry-level/low-end
>>         devices that have slow CPUs and limited memory. 
>>
>>         Battery life is another issue. Most of the mobile phone users
>>         want long battery life. DHT maintenance and handling searches
>>         have impact on idle state that is more important from battery
>>         life perspective than the active state (e.g. when user is
>>         I was considering a similar solution to the one that Alan
>>         proposed however as Eunsoo said it would be quite difficult
>>         to control the number of connections in DHT. We also have
>>         problems with handling searches.
>>
>>         I assume that we will have some mobile terminals taking part
>>         in DHT and some accessing resources stored in DHT using a
>>         client protocol.
>>
>>
>>         Marcin
>>
>>             *Cc:* Henry Sinnreich; Avshalom Houri; Philip Matthews;
>>             P2PSIP Mailing List
>>             The underling algorithm (e.g. a certain DHT algorithm)
>>             will dictate the number of connections even though there
>>             might be some room for adjustment. I don't think it is
>>             under complete control of individual peer in the case of
>>             known DHT algorithms.
>>
>>             I am not quite sure I understand the benefit of
>>             introducing such various levels of participation.
>>             Having a client protocol seems to be much simpler and
>>             easier than introducing these various levels of
>>             participation.
>>
>>             Thanks.
>>
>>             Eunsoo
>>
>>                 Henry Sinnreich wrote:
>>                 > Folks,
>>                 >

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 28 Jun 2007 10:34:32 -0700

>Nothing I have seen of developments indicate that the battery squeeze will be over any time soon. 

>Looking back a couple of years, I see mobile phones having far longer standby times than today (remember the 6210/6310 ;-) 

>The trajectory of battery capacity does not seem to improve any time soon.

This is an excellent observation and resembles how increased fuel efficiency of car engines is eaten up by people driving more mileage and bigger cars.

Henry

From: Greger V. Teigre [mailto:[email-masked]] 
Sent: Thursday, June 28, 2007 5:20 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [P2PSIP] do we need a client protocol?

Hi Marcin,
Yes, I have a fairly practical (and pessimistic) point of view. Nothing I have seen of developments indicate that the battery squeeze will be over any time soon. Looking back a couple of years, I see mobile phones having far longer standby times than today (remember the 6210/6310 ;-) The trajectory of battery capacity does not seem to improve any time soon.
Of course, there may be things you know that I don't ;-) Maybe you want to share?!
g-)

Hi Greger,

Marcin 

	
	
	Wei Gengyu wrote: 

	Hi, 

	 

	Gengyu

		----- Original Message ----- 

		-david

		Henry

		Power = A + nB

		-david 

		Hi,

		Marcin

			

			
			
			Thanks.
			
			Eunsoo

---

From: "David Barrett" <[email-masked]>
Date: Thu, 28 Jun 2007 13:33:39 -0700

Ok, so it seems fairly likely that a mobile unit can’t be a true SIP peer.
But based on all this I question if it’s even practical for a mobile unit to
be a SIP *client* because the simple of act of waiting for somebody to call
you will be prohibitively battery-draining.

First, Marcin, did I understand you correctly to say that simply being
connected to a WLAN – even if you don’t send any data – drains your battery
at a quick pace?  This alone suggests that there can be no long-lived
“listening” client-app on a mobile unit (SIP included) due to practical
battery limitations.  If this is true, then it makes the whole discussion
moot.

Second, assuming you can connect to and listen on a WLAN at all, then it’d
only work if you have a non-NAT’d, non-firewalled address (because anything
other is going to require constant NAT penetration/keepalive traffic).  80%
of real-world connections (and near 100% of actual WLANs) don’t have this
property.  So again, the discussion seems moot.

Third, assume it doesn’t cost battery life to listen, and assume you can
somehow have a relevant class of users reliably get non-NAT’d,
non-firewalled IP addresses.  With this sort of address you’re going to be
subject to the whims of the internet, which is a pretty harsh place – I’d
expect your phone would be undergoing almost constant scans from worms and
hackers, which would require it to constantly respond.  So again, your phone
is going to need to actively reject the 99% of “bad” traffic just to get the
“good” incoming call.  But the filtering is likely so expensive that the
battery life is unacceptable, and again, game over.

None of this has anything to do with SIP.  Unless I’m misunderstanding it,
it’s just not possible for a battery-conscious device to continuously listen
on an IP network at this point.  What am I missing?  

-david

  _____  

From: Greger V. Teigre [mailto:[email-masked]] 
Sent: Wednesday, June 27, 2007 11:15 PM
To: Wei Gengyu
Cc: [email-masked]
Subject: Re: [P2PSIP] do we need a client protocol?

Well, it's a bit more complicated than that. For one thing, there's a
difference between mobile and WLAN. Even with the power-saving mode of
802.11g for example, there's still more power drain when connected to WLAN,
than mobile. And on mobile, you have many scenarios, just take the GSM
(which I know the best), you have GSM High-Speed, still used by many
roadwarriors in many areas of the world, and you have GPRS/EDGE/3G data
connections. You can have three modes, each with different power
consumption: No connection (only voice), PDP context established, and active
connection. Real-life experimentation with various modes and applications
using these modes show that battery drainage is a real problem. 
As an example: a native Symbian application that looks up incoming calls
(over 3G data connection) where caller-id is not found in the local contact
list needs to have an active connection (not only PDP context), because in
order to show the caller's data, the lookup must be almost instantaneous. In
reality, it takes about 1 second.  This application is pretty much useless
if you actually make any calls, because at the end of the day, you don't
have battery left...
BTW, the same holds for innovative mobile VoIP apps such as Fling.

Wei Gengyu wrote: 

Hi, 

So, yes it is possible to have a phone in low-power standby mode but (for
example) listening for incoming TCP connections or UDP packets.

However, the power consumption to send messages is mostly converned when the
cell phone is in active mode. 

But, I do not think this should be dominate P2PSIP overlay design in this
stage.

Gengyu

----- Original Message ----- 

To: 'Henry Sinnreich' <mailto:[email-masked]>  ;
[email-masked] ; [email-masked] ; [email-masked] 

That makes sense.  So my next question is: what are the capabilities of
standby mode, and what triggers it going into “talk” mode?

It must be listening to some sort of cell signal even in standby mode, just
so it can receive phone calls.  Given this, when in standby mode, does it
also have access to the IP network?  In other words, is it possible to have
a phone in low-power standby mode but (for example) listening for incoming
TCP connections or UDP packets?

-david

  _____  

To: David Barrett; [email-masked]; [email-masked];

Under normal cell phone operation we have the talk time and the standby time
which is much longer.

Making a cell phone a full peer eliminates this distinction to a large
degree since the overlay maintenance messages keep the phone ‘talking’ all
the time.

Henry

  _____  

Cc: Henry Sinnreich; [email-masked]; [email-masked];
[email-masked]

I don’t know anything about mobile application design vis-à-vis battery
life, but I’m guessing power usage could be vastly oversimplified to
something like:

Power = A + nB

Where A is the overall cost of just having the device powered on and
listening to the radio, and B is the cost of sending a byte of data.  What
I’m wondering is, what is the ratio of A to B?  Can anyone give real-world
data?

For example, I’d accept that sending 200Mbps probably requires about 2x the
power 100Mbps: for a high enough value of ‘n’, then the constant A gets
marginalized.  But what about 200Kbps or 200bps?  For some low value of ‘n’,
then A dominates the power usage.

The reason I ask is I wonder if it’s even useful to discuss power usage for
something like P2PSIP.  It could be that even for a “real” peer, ‘n’ is so
low that the power consumption is dominated by other factors, rendering the
entire discussion moot.

-david 

  _____  

Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]

Hi,

We have wide variety of mobile terminals. The capabilities of mobile
terminals are constantly improving e.g. even now Nokia's N-series/E-series
devices are very powerful. From this reason some of mobile terminals may
become peers (depending on the case scenario: churn, size of the network).
However there are also many entry-level/low-end devices that have slow CPUs
and limited memory. 

Battery life is another issue. Most of the mobile phone users want long
battery life. DHT maintenance and handling searches have impact on idle
state that is more important from battery life perspective than the active
state (e.g. when user is calling/answering a call).

I was considering a similar solution to the one that Alan proposed however
as Eunsoo said it would be quite difficult to control the number of
connections in DHT. We also have problems with handling searches.

I assume that we will have some mobile terminals taking part in DHT and some
accessing resources stored in DHT using a client protocol.

Marcin

  _____  

 

The underling algorithm (e.g. a certain DHT algorithm) will dictate the
number of connections even though there might be some room for adjustment. I
don't think it is under complete control of individual peer in the case of
known DHT algorithms. 

I am not quite sure I understand the benefit of introducing such various
levels of participation.
Having a client protocol seems to be much simpler and easier than
introducing these various levels of participation. 

Thanks.

Eunsoo

> From: Dean Willis [mailto:[email-masked]
<mailto:[email-masked]> ]

  _____  

  _____

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 28 Jun 2007 16:44:58 -0700

David,

>Unless I'm misunderstanding it, it's just not possible for a battery-conscious device to continuously listen on an IP network at this point.  

>What am I missing? 

I believe you are not missing anything, and 2G/3G mobile phones are listening only to L2 messages.

Can someone from the mobile phone industry validate this?

What about WiFi phones?

Thanks, Henry

From: David Barrett [mailto:[email-masked]] 
Sent: Thursday, June 28, 2007 1:34 PM
To: 'Greger V. Teigre'; 'Wei Gengyu'
Cc: [email-masked]
Subject: RE: [P2PSIP] do we need a client protocol?

Ok, so it seems fairly likely that a mobile unit can't be a true SIP peer.  But based on all this I question if it's even practical for a mobile unit to be a SIP *client* because the simple of act of waiting for somebody to call you will be prohibitively battery-draining.

First, Marcin, did I understand you correctly to say that simply being connected to a WLAN - even if you don't send any data - drains your battery at a quick pace?  This alone suggests that there can be no long-lived "listening" client-app on a mobile unit (SIP included) due to practical battery limitations.  If this is true, then it makes the whole discussion moot.

Second, assuming you can connect to and listen on a WLAN at all, then it'd only work if you have a non-NAT'd, non-firewalled address (because anything other is going to require constant NAT penetration/keepalive traffic).  80% of real-world connections (and near 100% of actual WLANs) don't have this property.  So again, the discussion seems moot.

Third, assume it doesn't cost battery life to listen, and assume you can somehow have a relevant class of users reliably get non-NAT'd, non-firewalled IP addresses.  With this sort of address you're going to be subject to the whims of the internet, which is a pretty harsh place - I'd expect your phone would be undergoing almost constant scans from worms and hackers, which would require it to constantly respond.  So again, your phone is going to need to actively reject the 99% of "bad" traffic just to get the "good" incoming call.  But the filtering is likely so expensive that the battery life is unacceptable, and again, game over.

None of this has anything to do with SIP.  Unless I'm misunderstanding it, it's just not possible for a battery-conscious device to continuously listen on an IP network at this point.  What am I missing?  

-david

Wei Gengyu wrote: 

Hi, 

 

Gengyu

	----- Original Message ----- 

	-david

	Henry

	Power = A + nB

	-david 

	Hi,

	Marcin

		

			 

		
		
		Thanks.
		
		Eunsoo

---

From: Dean Willis <[email-masked]>
Date: Fri, 29 Jun 2007 00:57:04 -0500

On Jun 28, 2007, at 3:33 PM, David Barrett wrote:

> Ok, so it seems fairly likely that a mobile unit can’t be a true  
> SIP peer.  But based on all this I question if it’s even practical  
> for a mobile unit to be a SIP *client* because the simple of act of  
> waiting for somebody to call you will be prohibitively battery- 
> draining.

It all depends . . . on which radio network you are using, mostly.

In some environments, the IP stack is effectively turned "off", and  
there is no radio channel allocated for a device that's just  
"waiting". Instead, the layer 2 switching device (aka PDSN or GGSN),  
when it has a packet for the mobile, sends a "paging" message to the  
mobile to wake it up. The mobile then sets up a layer 2 session, over  
which it establishes an IP default route, and eventually receives the  
"packet". This might take upwards of 10 seconds, and messes with many  
IP applications badly. But it saves a lot of power.

And if you're doing "outbound" style keepalive, you won't get this  
sort of efficiency. And it's just not going to let that mobile be a  
full DHT node.
>
>
> First, Marcin, did I understand you correctly to say that simply  
> being connected to a WLAN – even if you don’t send any data –  
> drains your battery at a quick pace?  This alone suggests that  
> there can be no long-lived “listening” client-app on a mobile unit  
> (SIP included) due to practical battery limitations.  If this is  
> true, then it makes the whole discussion moot.

This varies, but with today's chipsets and batteries, a typical PDA  
device can run its WLAN  in "listen" mode for only a few (perhaps up  
to 6) hours. There are some proprietary tricks to extend this when  
there's no active communication, some of which (especially if the PDA  
and its access point collaborate) can run the standby time up to  
several days, much like the standby time on a mobile phone network  
(and pretty much using the same tricks). If the device is actively  
transmitting, talk time plummets rapidly.

Now, is 6 hours enough? It'll certainly get the floor boss of a  
warehouse through a 4 hour shift using his PDA-phone. He changes  
batteries on his lunch break, then works another 4 hours.

 From an emergency responder perspective: 6 hours is a lot more time  
than one might get from a Scott airpack: http:// 
www.scotthealthsafety.com/airpak.htm. You'll be back at the truck  
recharging long before the battery goes dead from standby load.
> Second, assuming you can connect to and listen on a WLAN at all,  
> then it’d only work if you have a non-NAT’d, non-firewalled address  
> (because anything other is going to require constant NAT  
> penetration/keepalive traffic).  80% of real-world connections (and  
> near 100% of actual WLANs) don’t have this property.  So again, the  
> discussion seems moot.
Many of the mobile-operator networks are designed with no NATs and  
firewalls between the mobile device and its upstream IP elements for  
just this reason. Hence, no need for NAT-keepalive.

> Third, assume it doesn’t cost battery life to listen, and assume  
> you can somehow have a relevant class of users reliably get non- 
> NAT’d, non-firewalled IP addresses.  With this sort of address  
> you’re going to be subject to the whims of the internet, which is a  
> pretty harsh place – I’d expect your phone would be undergoing  
> almost constant scans from worms and hackers, which would require  
> it to constantly respond.  So again, your phone is going to need to  
> actively reject the 99% of “bad” traffic just to get the “good”  
> incoming call.  But the filtering is likely so expensive that the  
There can certainly be firewalls and or NATs "further out", beyond  
the upstream IP device. Again, this is typical in mobile operator  
environments.
> None of this has anything to do with SIP.  Unless I’m  
> misunderstanding it, it’s just not possible for a battery-conscious  
> device to continuously listen on an IP network at this point.  What  
> am I missing?

Details, mostly. Missing details. It's an ugly world out there, and  
much of what we imagine to be the Internet isn't what we imagine it  
to be.

--
Dean

---

From: "David Barrett" <[email-masked]>
Date: Fri, 29 Jun 2007 00:02:27 -0700

> From: Dean Willis [mailto:[email-masked]]
> > None of this has anything to do with SIP.  Unless I'm
> > misunderstanding it, it's just not possible for a battery-conscious

Good, thanks for those details.  So:

- Some mobile applications listen for a 'page' to fire up the IP stack
- Some PDAs can go 4-6 hours in IP "listen" mode.
- Many mobile IP devices have no NAT/FW
	. But they might have them "further out"

These details seem to largely reaffirm that IP-based applications generally
can't spend a long time in "listen" mode without high battery drain, and
thus maybe it's a distraction to even spend energy discussing it in the
context of P2PSIP.

Until the whole IP network listen/battery-life thing has been worked out in
a more general fashion (ie, one that doesn't require layer 2 tricks between
the client and the network), it's probably premature to worry about.

Do you agree, or did I misunderstand your conclusion?

-david

---

From: <[email-masked]>
Date: Fri, 29 Jun 2007 10:24:10 +0300

Hi David,

Do I understand you correctly: According to your conclussion VoIP is not
going to work on any battery powered device?

We may forget about billions of phones out there, battery limitations,
nat traversal and security issues - who cares about them. The world is
perfect! 

Marcin  

>From: ext David Barrett [mailto:[email-masked]] 
>Sent: 29 June, 2007 10:02
>To: 'Dean Willis'
>Cc: [email-masked]
>> much of what we imagine to be the Internet isn't what we 
>imagine it to 
>> be.
>
>These details seem to largely reaffirm that IP-based 
>applications generally can't spend a long time in "listen" 
>mode without high battery drain, and thus maybe it's a 
>distraction to even spend energy discussing it in the context 
>of P2PSIP.
>
>Until the whole IP network listen/battery-life thing has been 
>worked out in a more general fashion (ie, one that doesn't 
>require layer 2 tricks between the client and the network), 
>it's probably premature to worry about.
>

---

From: "Dominguez, Curro, VF-ES \(fdoming4\)" <[email-masked]>
Date: Fri, 29 Jun 2007 09:40:25 +0200

Hi all, 

I think most of you will find useful the details provided in this article

http://blogs.msdn.com/windowsmobile/archive/2006/08/04/689069.aspx

I've been researching some time about the impact that applications have on battery life, but I have to say there's no much information. (So I'd be willing to read the paper of Marcin's mates at Nokia). 

In the meantime, my humild opinion is that, although important, it's not something that P2PSIP group should worry about at the moment. I mean it's a more general problem related to data connections and that is shared by all the IP-based applications in the mobile phone, not only a P2PSIP client. 

Best regards, 

Curro Domínguez

-----Mensaje original-----
De: David Barrett [mailto:[email-masked]] Enviado el: viernes, 29 de junio de 2007 9:02
Para: 'Dean Willis'
CC: [email-masked]
Asunto: RE: [P2PSIP] do we need a client protocol?

> much of what we imagine to be the Internet isn't what we imagine it to 
> be.

These details seem to largely reaffirm that IP-based applications generally can't spend a long time in "listen" mode without high battery drain, and thus maybe it's a distraction to even spend energy discussing it in the context of P2PSIP.

Until the whole IP network listen/battery-life thing has been worked out in a more general fashion (ie, one that doesn't require layer 2 tricks between the client and the network), it's probably premature to worry about.

-david

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip
Confidencialidad 
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios y propiedad de Vodafone España. Queda prohibida su divulgación, copia o distribución a terceros sin la previa autorización escrita de Vodafone España, en virtud de la legislación vigente. En el caso de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta circunstancia mediante reenvío a la dirección electrónica del remitente y la destrucción del mismo.

Confidentiality 
The information in this e-mail and in any attachments is classified as Vodafone España Confidential and Proprietary Information and solely for the attention and use of the named addressee(s). You are hereby notified that any dissemination, distribution or copy of this communication is prohibited without the prior written consent of Vodafone España and is s strictly prohibited by law. If you have received this communication in error, please, notify the sender by reply e-mail .

---

From: <[email-masked]>
Date: Fri, 29 Jun 2007 11:04:58 +0300

Curro,

I agree with you that it is not our goal to solve battery problems however we are going to design peer and client protocols and select a DHT. In the design process we should consider battery limitations, in a similar way as NAT traversal and security issues. It is much more efficient to make educated choices at the begging of the design process than put a lot of effort redesigning broken protocols.

Marcin  

>From: ext [email-masked] [mailto:[email-masked]] 
>Sent: 29 June, 2007 10:40
>To: David Barrett; Dean Willis
>Cc: [email-masked]
>I've been researching some time about the impact that 
>applications have on battery life, but I have to say there's 
>no much information. (So I'd be willing to read the paper of 
>Marcin's mates at Nokia). 
>
>In the meantime, my humild opinion is that, although 
>important, it's not something that P2PSIP group should worry 
>about at the moment. I mean it's a more general problem 
>related to data connections and that is shared by all the 
>IP-based applications in the mobile phone, not only a P2PSIP client. 
>
>Best regards, 
>
>Curro Domínguez
>
>Este correo electrónico y, en su caso, cualquier fichero anexo 
>al mismo, contiene información de carácter confidencial 
>exclusivamente dirigida a su destinatario o destinatarios y 
>propiedad de Vodafone España. Queda prohibida su divulgación, 
>copia o distribución a terceros sin la previa autorización 
>escrita de Vodafone España, en virtud de la legislación 
>vigente. En el caso de haber recibido este correo electrónico 
>por error, se ruega notificar inmediatamente esta 
>circunstancia mediante reenvío a la dirección electrónica del 
>remitente y la destrucción del mismo.
>
>Confidentiality
>The information in this e-mail and in any attachments is 
>classified as Vodafone España Confidential and Proprietary 
>Information and solely for the attention and use of the named 
>addressee(s). You are hereby notified that any dissemination, 
>distribution or copy of this communication is prohibited 
>without the prior written consent of Vodafone España and is s 
>strictly prohibited by law. If you have received this 
>communication in error, please, notify the sender by reply e-mail .
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 29 Jun 2007 10:07:20 -0500

On Jun 29, 2007, at 2:02 AM, David Barrett wrote:

> worked out in

Well, let's put it another way.

A lot of folks are putting a whole lot of money into IP applications  
running on mobile devices, and into mobile devices designed to run IP  
applications. I was playing with a SIP client on my Nokia 770 last  
night, and it's already been obsoleted by the new 800.

Folks are also putting a lot of money into better 802.11 chipsets,  
but we can't expect a "magic bullet" on that front that will turn a  
PDA into a data-center-class server.

So the reality is, we're going to have a whole lot of boxes running  
in mobile configurations, and these boxes are not going to have all  
the capabilities of server-class machines, and that's just the way it  
is going to be for quite a long time.

Now, do you want to pay attention to half the nodes on the Internet,  
or not?

--
Dean

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 29 Jun 2007 08:58:52 -0700

To bring the discussion back to the peer and client protocols, here is
what the SIP-DHT interface has to support for the peer protocol
(courtesy Salman Baset):

*	Join
*	Leave
*	Lookup
*	Publish
*	Remove

And here what the client protocol would need to support IMHO, for those
who want to use the client protocol:

*	Lookup
*	Publish
*	Remove

Thanks, Henry

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Friday, June 29, 2007 8:07 AM
To: David Barrett
Cc: [email-masked]
Subject: Re: [P2PSIP] do we need a client protocol?

--
Dean

---

From: Philip Matthews <[email-masked]>
Date: Fri, 29 Jun 2007 12:10:15 -0400

On 29-Jun-07, at 04:04 , <[email-masked]>  
<[email-masked]> wrote:

>
> In the design process we should consider battery limitations, in a  
> similar way as NAT traversal and security issues.

I am not against this idea, but I do have a concern.

There has been quite a bit of work elsewhere in the IETF in NAT  
traversal and security. There are a number of basic tools available,  
and the group is mostly adapting tools developed in other groups to  
the P2PSIP context. There are also a number of people active in  
P2PSIP who are familiar with these tools.

I am not sure the same can be said for battery limitations. Is there  
a working group somewhere which is studying the general problem of  
running IP on devices with battery limitations?

- Philip

---

From: "David Barrett" <[email-masked]>
Date: Fri, 29 Jun 2007 17:52:29 -0700

> Now, do you want to pay attention to half the nodes on the Internet,

Heh, if half the nodes on the internet actually were mobile devices, maybe
I'd agree.  But in the real world, that number is far smaller.

We're finding it hard enough to make P2PSIP relevant on the internet nodes
that *do* exist, so let's stay focused on reality.

Once we have proven P2PSIP actually works for real-world users on the
real-world internet, then let's worry about possible future internets.

-david