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

From: "Willekens, Marc" <[email-masked]>
Date: Sun, 8 Jul 2007 10:51:22 +0200

-----Original Message-----
From: Willekens, Marc 
Sent: vrijdag 6 juli 2007 16:53
To: 'Alan Johnston'
Subject: RE: [P2PSIP] do we need a client protocol?

Don't we have to consider the "p2p" as a kind of intermediary service
routing layer? The peer contributes to the distributed routing based on
its own provided resources, which is, as indicated in many mailings, a
important point to consider for mobile devices, for power, memory and
bandwidth consumption. As such, there is a strong requirement to have a
dedicated and optimized protocol for the service routing layer which can
optimally be implemented and supported by special hardware, in the same
way as is done for the fast IP routers, and which avoids influences to
the traffic destined to/originated from the device acting both as an
routing intermediary and as an end-node.
Br,
Marc.

-----Original Message-----
From: Alan Johnston [mailto:[email-masked]] 
Sent: woensdag 27 juni 2007 1:05
To: Henry Sinnreich
Cc: Philip Matthews; Avshalom Houri; P2PSIP Mailing List
Subject: Re: [P2PSIP] do we need a client protocol?

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 witFrom [email-masked] Sun Jul 08 04:53:11 2007
Content-class: urn:content-classes:message
Subject: FW: [P2PSIP] do we need a client protocol?
Date: Sun, 8 Jul 2007 10:51:22 +0200
From: "Willekens, Marc" <[email-masked]>
To: <[email-masked]>

-----Original Message-----
From: Willekens, Marc 
Sent: vrijdag 6 juli 2007 16:53
To: 'Alan Johnston'
Subject: RE: [P2PSIP] do we need a client protocol?

Don't we have to consider the "p2p" as a kind of intermediary service
routing layer? The peer contributes to the distributed routing based on
its own provided resources, which is, as indicated in many mailings, a
important point to consider for mobile devices, for power, memory and
bandwidth consumption. As such, there is a strong requirement to have a
dedicated and optimized protocol for the service routing layer which can
optimally be implemented and supported by special hardware, in the same
way as is done for the fast IP routers, and which avoids influences to
the traffic destined to/originated from the device acting both as an
routing intermediary and as an end-node.
Br,
Marc.

-----Original Message-----
From: Alan Johnston [mailto:[email-masked]] 
Sent: woensdag 27 juni 2007 1:05
To: Henry Sinnreich
Cc: Philip Matthews; Avshalom Houri; P2PSIP Mailing List
Subject: Re: [P2PSIP] do we need a client protocol?

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.

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.

Thoughts?

Thanks,
Alan

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

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.

Thoughts?

Thanks,
Alan

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

---

From: "Willekens, Marc" <[email-masked]>
Date: Sun, 8 Jul 2007 10:52:00 +0200

________________________________

From: Willekens, Marc 
Sent: vrijdag 6 juli 2007 17:11
To: [email-masked]'
Subject: RE: [P2PSIP] do we need a client protocol?

Hi Marcin,
You're right. In a p2p, the "standby time" of the battery can negatively
be influenced. As such, we really have to differentiate between "transit
traffic" and node related traffic (from/towards an application). For the
transit traffic, an optimized protocon the service advertisements from the
a
change

---

From: "Willekens, Marc" <[email-masked]>
Date: Sun, 8 Jul 2007 10:52:00 +0200

From: Willekens, Marc 

Hi Marcin,
You're right. In a p2p, the "standby time" of the battery can negatively
be influenced. As such, we really have to differentiate between "transit
traffic" and node related traffic (from/towards an application). For the
transit traffic, an optimized protocol is required which can be
supported by hardware. For the node outgoing traffic, the service
routing layer needs the knowledge where to route the message towards:
this could be a fixed proxy function or a p2p distributed location.
 
br,
Marc.

From: [email-masked] [mailto:[email-masked]]

Sent: woensdag 27 juni 2007 9:33
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:
		> - Other uses besides SIP. Business planning folks may
not care about the 
		> ol is required which can be
supported by hardware. For the node outgoing traffic, the service
routing layer needs the knowledge where to route the message towards:
this could be a fixed proxy function or a p2p distributed location.
 
br,
Marc.

From: [email-masked] [mailto:[email-masked]]

Sent: woensdag 27 juni 2007 9:33
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:
		> - Other uses besides SIP. Business planning folks may
not care about the 
		> From: Dean Willis [mailto:[email-masked] ]
		>> DHTs, how do we allow you to be in the overlay and
not store resources 
		> Well, that certainly depends on the DHT algorithm
involved. It certainly
		>> terminology for over a year now. Just looks like a
souce of confusion.
		> contribute resources, and sometimes not have a
high-bandwidth connection 
		>> If we do go this way, there is one subtle point. If I
join the overlay
		> 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. 
		>> If we are so opposed to client for confusion with SIP
UAs, lets pick a
		> Because in 15 minutes it might roam onto a WiFi net
and therefore change

---

From: "Willekens, Marc" <[email-masked]>
Date: Sun, 8 Jul 2007 10:52:24 +0200

From: Willekens, Marc 
Sent: vrijdag 6 juli 2007 17:34
To: 'David Barrett'
Subject: RE: [P2PSIP] do we need a client protocol?

Hi David,
Yes, we can try to consider the ratio between A and B, but more important is the unknown and uncontrolable value of "n".
When your phone is used as a "transfer node" in the p2p routing network, then you are influenced by all the other peers making use of your transfer function. Every time they setup a media session, your device is negatively influenced.  If we want the p2p to become successful for limited devices and to avoid that people will turn of their phones to avoid the additional uncontrollable battery consumption, a kind of dynamic resource indication function is required by the p2p protocol. E.g. when a certain battery level threshold is reached, a decision can be made that the device will no longer be an resource contributing element in the p2p network. This is important to consider to reserve the resources for emergency calls.
br,
Marc. 

From: David Barrett [mailto:[email-masked]] 
Sent: woensdag 27 juni 2007 19:06
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [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?

	
	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.

		 

	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:
		> - Other uses besides SIP. Business planning folks may not care about the 
		>> DHTs, how do we allow you to be in the overlay and not store resources 
		>>
		> (not
		>
		> Well, that certainly depends on the DHT algorithm involved. It certainly
		>> terminology for over a year now. Just looks like a souce of confusion.
		>>
		>
		> contribute resources, and sometimes not have a high-bandwidth connection 
		>> If we do go this way, there is one subtle point. If I join the overlay
		>>
		> but
		>
		> 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. 
		>
		>> If we are so opposed to client for confusion with SIP UAs, lets pick a
		>>
		> new 
		>
		> Because in 15 minutes it might roam onto a WiFi net and therefore change
		> it service offering. 
		>
		> --
		> Dean
		>