Subject: [P2PSIP] Concepts document: proposal for active/passive peer terminology

From: Dean Willis <[email-masked]>
Date: Wed, 13 Jun 2007 17:49:34 -0500

I'm updating the concepts draft, and wanted to kick this around a  
little bit before I put it into the draft.

We've sort of come up with three different sorts of nodes:

1) The "full peer" nodes that actively provide resources (like  
storage and transport) to the overlay and speak the P2SIP Peer Protocol.

2) Less-than-full peer nodes that either speak some subset of the  
P2PSIP Peer Protocol (which we called the P2PSIP Client Protocol) or  
just natively access the distributed database, but that are lazy and  
do not contribute their own resources to the overlay.

3) "Clients", which are either #2 above, or just plain-old-SIP UAs  
depending on who you talk to.

I hereby propose to client this up a bit, based on suggestions made  
on the list, by having two sorts of peers; "active" and "passive",  
SIP UAs, P2PSIP Peer Protocol, and SIP. Note that I'm not including  
P2PSIP Client Protocol here.

An "active peer" is one that contributes resources. A "passive peer"  
is one that doesn't. The choice of which mode to operate in could be  
a matter of implementation, or configuration, or could be a runtime  
decision based on the resources (memory, bandwidth, power, etc.)  
available to the peer.

Peers advertise services that they are contributing with the  
distributed database. So a peer that has advertised any services at  
all could be said to be "active", and a peer that hasn't advertised  
any could be said to be "passive".

Things like "transport", "storage", "STUN", "STUN Relay", "SIP  
Outbound Proxy" and the like would be "Services". Obviously, not all  
peers would offer all services. We'd expect that most would offer  
"transport" and "storage", but probably only specialized nodes would  
offer "SIP Outbound Proxy".

I think this greatly simplifies the semantic morass in which we've  
been wading.

How does it sound to you?

--
Dean

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

---

From: Avshalom Houri <[email-masked]>
Date: Thu, 14 Jun 2007 12:44:49 +0300

Sounds good and simple.

--Avshalom

Dean Willis <[email-masked]> 
14/06/2007 01:49

To
P2PSIP Mailing List <[email-masked]>
cc
Philip Matthews <[email-masked]>
Subject
[P2PSIP] Concepts document: proposal for active/passive peer terminology

--
Dean

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 14 Jun 2007 09:16:03 -0400

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)

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.

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

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?

David

On 6/14/07, Avshalom Houri <[email-masked]> wrote:
>
>
> Sounds good and simple.
>
> --Avshalom
>
>
>
>
>
>
>  *Dean Willis <[email-masked]>*
>
> 14/06/2007 01:49
>   To
> P2PSIP Mailing List <[email-masked]>  cc
> Philip Matthews <[email-masked]>  Subject

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: "Bill Mccormick" <[email-masked]>
Date: Thu, 14 Jun 2007 09:47:43 -0400

It sounds like Dean is saying:

an active peer is a fully participating node in the DHT.
a passive peer can access the DHT "natively" but is not actually a DHT node
a client is just a SIP UA client and it treats the DHT (more or less) as a
proxy server.

Is this correct?

Bill McCormick
Nortel

On 6/14/07, David A. Bryan <[email-masked]> wrote:
> "non-contributing peer" who isn't even part of the overlay ( i.e., no
> Peer-ID)
>
> >   *Dean Willis <[email-masked] >*
> >
> > 14/06/2007 01:49
> >    To
> www.SIPeerior.com <http://www.sipeerior.com/>

-- 
Bill McCormick

---

From: Philip Matthews <[email-masked]>
Date: Thu, 14 Jun 2007 10:18:36 -0400

Two comments on this proposal:

(1) This proposal makes a binary distinction between peers that are  
willing to store data for other peers and peers that are not willing  
to store data. However, what I think might reflect reality better is  
a measure of how much storage a peer is willing to offer. Consider  
for example a softphone running on a typical modern PC, vs a  
hardphone. The former has lots of disk to store data on, while the  
latter typically has a very limited amount of flash memory. In our  
deskphone product, for example, we use flash memory, and space in our  
flash is always at a premium.

To be precise: Rather that a peer advertising "I am willing to  store  
data", a peer might instead need to advertise "I am willing to store  
N KBytes of data".

Now, if the amount of data that we want to store in the Distributed  
Database is small, then making this distinction is not important. If  
we store just contact information, then I think we can ignore this  
distinction. However, if we start using the Distributed Database to  
store other things, then I think this distinction will become important.

(2) As I have said before, I really, really want to see good examples  
of why we want to make this distinctions between types of peers (or  
whatever we call them). Yes, we could design a system that allows for  
great flexibility in types of peers allowed, but I want to first  
understand why this flexibility is useful.

To be concrete: I suggest having a section in the document that  
discusses these possibilities (and any others that people can think  
of), but I suggest holding off in giving them names and elevating  
them to formal "concepts" in the document until someone argues why  
one of these is of particular interest.

To apply my own suggestion, I consider my comment (1) above to be a  
concept that is "waiting-in-the-wings".  If I see people starting to  
suggest using the distributed database to store lots of different  
things, then I will bring this point up again and probably write an I- 
D that argues that we need to make this distinction. Until then, I am  
just keeping it in the back of my mind.

- Philip

On 13-Jun-07, at 18:49 , Dean Willis wrote:

> P2PSIP Peer Protocol (which we called the P2PSIP Client Protocol)  
> or just natively access the distributed database, but that are lazy  
> and do not contribute their own resources to the overlay.
>
> An "active peer" is one that contributes resources. A "passive  
> peer" is one that doesn't. The choice of which mode to operate in  
> could be a matter of implementation, or configuration, or could be  
> a runtime decision based on the resources (memory, bandwidth,  
> power, etc.) available to the peer.
>
> Outbound Proxy" and the like would be "Services". Obviously, not  
> all peers would offer all services. We'd expect that most would  
> offer "transport" and "storage", but probably only specialized  
> nodes would offer "SIP Outbound Proxy".
>

---

From: Gustavo García <[email-masked]>
Date: Thu, 14 Jun 2007 16:55:31 +0200

> understand why this flexibility is useful.

IMHO we only need to make the distinction between nodes which participate in
the location of resources (participate in the DHT structure) and those who
only make use of the resource location functions (sending PUT/GET requests).

We need to make this distinction because Peers need a PeerID while for
Clients this is not clear, because the protocol primitives implemented in
Peers are different from those in Clients, because bootstrapping/joining
procedures are different (clients don't need to be placed in the DHT
structure) and because probably they also have different security
requirements (it is more critical to authorize a peer than a client).  

Personally I like the names Peer and Client but If somebody feels that
Client is a confuse name we only need to look for other term (not trying to
create new concepts for nodes depending on the services provided).

G.

---

From: Philip Matthews <[email-masked]>
Date: Thu, 14 Jun 2007 11:05:48 -0400

> requirements (it is more critical to authorize a peer than a client).

I agree that clients might not need peer IDs, and might have a  
different protocol stack,
but why do you want clients? What motives you to write additional  
software to support
the concept of a client?

- Philip

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 14 Jun 2007 10:07:18 -0500

I want to agree with Philip, and provide a wake-up call...

> (2) As I have said before, I really, really want to see good examples  of 
> why we want to make this distinctions between types of peers (or  whatever 
> we call them). Yes, we could design a system that allows for  great 
> flexibility in types of peers allowed, but I want to first  understand why 
> this flexibility is useful.
>
> To be concrete: I suggest having a section in the document that  discusses 
> these possibilities (and any others that people can think  of), but I 
> suggest holding off in giving them names and elevating  them to formal 
> "concepts" in the document until someone argues why  one of these is of 
> particular interest.

>From the meeting minutes at 
http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html...

P2PSIP Client Discussion, Spencer Dawkins

What are Clients?  Not garden variety SIP UACs, nor the equivalent of
 "peers."

Issue: Clients as storage nodes.  No credible use case so far; deferred.

[ Discussion ensued at mic.

  Philip: Why do we need P2PSIP clients?  The answer will drive whether or
  not we use them.

  Brian Rosen (as individual): I don't understand P2PSIP clients.  We need
  to get rid of it and focus on normal SIP clients.

  Philip: Those that want P2PSIP Clients need to come up with a good use
  case by Chicago IETF.  If they do not come up by then, the P2PSIP Clients
  go away. ]

Hum - Should the wg work on the normal garden variety SIP UA connected to
      the DHT via some box (a SIP proxy coupled to a peer)?

[ Hum indicated yes.
  Those that want a P2PSIP Client distinct from a normal SIP client need to
  get together and work on use cases. ]

So - is this actually happening? Or are we trying to come up with a name for 
a concept we don't need/don't know WHY we need?

Just curious... the 00 draft cutoff being Monday, July 2, and all that.

Spencer

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 14 Jun 2007 08:21:57 -0700

At this point, I would like to share some text edited by Marcin
Matuszewski for a requirements I-D for the P2P SIP that we are still
working on:
....
One assumption of DHT networks on the Internet could be that the network
nodes are homogenous, and they have enough processing power and memory
to run DHT networks without any limits. This assumption does not hold
however if we consider mobile devices such as mobile phones, PDAs, or
WiFi phones. Mobile devices are heterogeneous. Low-end devices may have
a little memory, a slow CPU and may not support fast packet radio
interfaces. On the other hand, high-end devices may have significantly
higher capabilities: Fast radio interfaces, more memory and faster CPU
then they their less advanced counterparts.

>From this reason we can classify network nodes into two categories:
Mainly those that have enough CPU power, memory and fast network
interface to run P2PSIP peer protocol and those that may not have enough
capabilities to become P2PSIP peers.

Besides, if we consider the issue of NAT traversal, a very powerful
mobile device can be behind a restrictive NAT. This may require the
device to establish a TCP or TLS connection towards a TURN server. If
the connection has to be maintained for a long period, it may drain the
device battery. From these reasons, not all battery powered devices
though having enough capabilities to run the peer protocol will still
not be able to become P2PSIP peers.

Essentially, any DHT overlay network can support two basic operations:
PUT and GET. In the P2PSIP overlay a PUT operation is used to insert,
modify, or delete data in the overlay,such as user or resource records.
A GET operation is used to retrieve data stored in the overlay. Clients
should be able to store, modify, delete and retrieve user and resource
records from the overlay; in the P2P language they must support PUT and
GET operations.
....
Note again that clients do not participate in the maintenance of the
DHT, but may use the DHT for certain functions, such as storage and
retrieval of data.

Henry

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Thursday, June 14, 2007 5:07 PM
To: P2PSIP Mailing List
Subject: Re: [P2PSIP] Concepts document: proposal for
active/passivepeerterminology

> (2) As I have said before, I really, really want to see good examples
of 
> To be concrete: I suggest having a section in the document that
discusses 

  Philip: Why do we need P2PSIP clients?  The answer will drive whether
or
  not we use them.

  Brian Rosen (as individual): I don't understand P2PSIP clients.  We
need
  to get rid of it and focus on normal SIP clients.

  Philip: Those that want P2PSIP Clients need to come up with a good use
  case by Chicago IETF.  If they do not come up by then, the P2PSIP
Clients
  go away. ]

Hum - Should the wg work on the normal garden variety SIP UA connected
to
      the DHT via some box (a SIP proxy coupled to a peer)?

[ Hum indicated yes.
  Those that want a P2PSIP Client distinct from a normal SIP client need
to
  get together and work on use cases. ]

So - is this actually happening? Or are we trying to come up with a name
for 
a concept we don't need/don't know WHY we need?

Spencer

---

From: Gustavo García <[email-masked]>
Date: Thu, 14 Jun 2007 17:38:10 +0200

> From: Philip Matthews [mailto:[email-masked]]
> Sent: jueves, 14 de junio de 2007 17:06
> To: Gustavo García
> Cc: 'Dean Willis'; 'P2PSIP Mailing List'
> Subject: Re: [P2PSIP] Concepts document: proposal for active/passive
> peerterminology
> 
> 

I have a messenger like application in my mobile phone, and I don't want to
participate in the DHT to save the battery life.  I could be a "traditional"
SIP UA and register and make calls using SIP proxy services in the overlay,
but how am I going to retrieve my buddy list stored in the overlay?  Are we
going to have XCAP proxy services in the overlay?  Are we going to have a
proxy service for each new "capability" needed?  If you allow me to be a
P2PSI Client I can put this kind of intelligence in my end device
independently of the services provided in the overlay (I only need a PUT/GET
interface or something similar).  

Best regards,
G.

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 14 Jun 2007 17:43:56 +0200

Spencer Dawkins wrote:
> for a concept we don't need/don't know WHY we need?

As far as I recall, the only credible use case which justifies the 
existence of the "client" concept is that where a "non contributing" 
node wants to store/retrieve in the overlay something which can't be 
encoded in SIP (REGISTER?) messages (e.g. public keys, VM records...).
Since such functionalities are not required to realize what the group 
has been chartered for (are they?) and perhaps they could be used in 
centralized environments too, well... I personally hope that it _is_ 
happening and that we get rid of "clients" before the next meeting.

-- 
Ciao,
Enrico

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 14 Jun 2007 14:01:48 -0400 (EDT)

Further elaborating the point by Henry/Marcin on the usage 'clients' and 
the variety of 'peers':

1) A device's processing/connection capabilites are "limited" and 
particpating in a full blown DHT is a big hit on its resources such as 
limited battery-life or bandwidth.

2) The nodes are behind a "restricted NAT/firewall" and it might be 
feasible to leave them out of a DHT than to adopt the best NAT traversal 
solution that allows these nodes to fully participate in the DHT. Skype 
adopts this solution.

3) The concept of a 'client' easily lends itself to the creation of 
hierachical overlays.

Peers perform the basic routing function but they can also have different 
capabilities. For concept draft purposes, I don't think we need to further 
disambiguate the peer concept based on the capabilities such as storage, 
CPU or b/w; that should be left to the overlay designer.

-salman

---

From: Enrico Marocco <[email-masked]>
Date: Thu, 14 Jun 2007 21:10:38 +0200

> solution that allows these nodes to fully participate in the DHT. Skype

100% agree; if a device doesn't want (or has not enough resources or is
not welcome) to participate in an overlay, it can just use it, simply
acting as a SIP user agent.  I don't get why one should consider it a
client, i.e. something more than a UA, but non really a peer.

> 3) The concept of a 'client' easily lends itself to the creation of

Uh?  Can you elaborate a little?

> Peers perform the basic routing function but they can also have
> different capabilities. For concept draft purposes, I don't think we
> need to further disambiguate the peer concept based on the capabilities
> such as storage, CPU or b/w; that should be left to the overlay designer.

I agree on this too.

---

From: Salman Abdul Baset <[email-masked]>
Date: Thu, 14 Jun 2007 16:24:04 -0400 (EDT)

> Uh?  Can you elaborate a little?

Imagine, there is an organization with a hierarchy and there is an overlay 
per hierarchy. There are at least two ways to connect such hierarhical 
overlays a) through peers that participate in both overlays b) peers in 
lower overlays act as clients to peers in higher overlays.

---

From: JiangXingFeng <[email-masked]>
Date: Fri, 15 Jun 2007 14:06:28 +0800

> Sent: Thursday, June 14, 2007 11:06 PM
> To: Gustavo García
> Cc: 'P2PSIP Mailing List'

Have we gotten rough consensus that we will use SIP protocol to transport
Peer protocol message. It is not the case, client may exist and client
protocol may exist. 
For SIP UA, the SIP message should be transported by the peers in the
overlay which would modify the message according to the SIP protocol. If
some peers on the path don't speak SIP, the message would be discarded by
these peers because of not speaking SIP. For example, there are some
STUN/TURN servers which do not speak SIP and be willing to be a peer in the
overlay. 

Am I missing something? 

Regards
JiangXingFeng

---

From: Dean Willis <[email-masked]>
Date: Fri, 15 Jun 2007 01:15:07 -0500

> a client is just a SIP UA client and it treats the DHT (more or less) as a

That's certainly a reasonable way to look at it.

I'm not sure that this means that the passive peer is not a DHT node --
I suspect that's an issue of the DHT protocol, not of the concept.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 15 Jun 2007 01:22:31 -0500

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

> 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

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.

> 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

---

From: Dean Willis <[email-masked]>
Date: Fri, 15 Jun 2007 01:25:36 -0500

> Just curious... the 00 draft cutoff being Monday, July 2, and all that.

Well, that's part of what I'm working on. So far, I'm now leaning
towards "client" being a modality of peer operation, meaning a peer that
can't afford to contribute resources "right now", rather than being an
entirely different thing from a peer.

--
Dean

---

From: "Greger V. Teigre" <[email-masked]>
Date: Fri, 15 Jun 2007 08:52:13 +0200

I'm struggling a bit with an underlying issue that seems to only be 
implicitly addressed (or I confuse things up).  To me it looks like 
people are talking about two different types of clients without not 
always specifying explicitly when they talk about which. I think all 
agree that the "client" does not have full peer capabilities. However, 
such a client can be aware of the overlay (as in routing or having some 
storage capability) and as such participate in the overlay as a "lesser 
peer" or it can be ignorant of the overlay, except that it knows that 
some entity offers GET/PUT. So, it needs to have a full peer, which acts 
as a "gateway" into the overlay.

So, a first decision would be to decide whether a "lesser peer" should 
be supported or if only access through a "gateway" should be allowed. A 
second decision would be whether SIP should be used for communication 
between client and "gateway peer" or some other client protocol.
g-)

Enrico Marocco wrote:
> Spencer Dawkins wrote:
>> So - is this actually happening? Or are we trying to come up with a 
>> name for a concept we don't need/don't know WHY we need?
>
> ------------------------------------------------------------------------
>

---

From: <[email-masked]>
Date: Fri, 15 Jun 2007 11:06:21 +0300

I fully agree with Salman.

Marcin 

>From: ext Salman Abdul Baset [mailto:[email-masked]] 
>Sent: 14 June, 2007 21:02
>To: Henry Sinnreich
>Cc: P2PSIP Mailing List
>Subject: RE: [P2PSIP] Concepts document: proposalfor 
>Further elaborating the point by Henry/Marcin on the usage 
>'clients' and the variety of 'peers':
>
>1) A device's processing/connection capabilites are "limited" 
>and particpating in a full blown DHT is a big hit on its 
>resources such as limited battery-life or bandwidth.
>
>2) The nodes are behind a "restricted NAT/firewall" and it 
>might be feasible to leave them out of a DHT than to adopt the 
>best NAT traversal solution that allows these nodes to fully 
>participate in the DHT. Skype adopts this solution.
>
>3) The concept of a 'client' easily lends itself to the 
>creation of hierachical overlays.
>
>
>>> flexibility in types of peers allowed, but I want to first  
>understand
>> why

---

From: <[email-masked]>
Date: Fri, 15 Jun 2007 11:27:08 +0300

Let's assume for a while that we have STUN/TURN servers that are external to the overlay but may assist peers/SIP UA in NAT traversal. If we get rid of the client protocol and clients how those servers can register to the DHT and advertise their services? Are we planning to force all of network entities to implement a SIP stack?

Marcin 

>From: ext JiangXingFeng [mailto:[email-masked]] 
>Sent: 15 June, 2007 09:06
>To: 'Philip Matthews'; 'Gustavo García'
>Subject: RE: [P2PSIP] Concepts document: proposal 
>foractive/passivepeerterminology
>
>> >> (2) As I have said before, I really, really want to see good 
>> >> examples of why we want to make this distinctions between 
>types of 
>> >> peers (or whatever we call them). Yes, we could design a system 
>> >> that allows for great flexibility in types of peers 
>allowed, but I 
>> >> want to first understand why this flexibility is useful.
>> >
>> > IMHO we only need to make the distinction between nodes which 
>> > participate in the location of resources (participate in the DHT 
>> > structure) and those who only make use of the resource location 
>> > functions (sending PUT/GET requests).
>> >
>> > We need to make this distinction because Peers need a PeerID while 
>> > for Clients this is not clear, because the protocol primitives 
>> > implemented in Peers are different from those in Clients, because 
>> > bootstrapping/ joining procedures are different (clients 
>don't need 
>> > to be placed in the DHT
>> different protocol stack, but why do you want clients? What motives 
>> you to write additional software to support the concept of a client?
>
>Have we gotten rough consensus that we will use SIP protocol 
>to transport Peer protocol message. It is not the case, client 
>may exist and client protocol may exist. 
>For SIP UA, the SIP message should be transported by the peers 
>in the overlay which would modify the message according to the 
>SIP protocol. If some peers on the path don't speak SIP, the 
>message would be discarded by these peers because of not 
>speaking SIP. For example, there are some STUN/TURN servers 
>which do not speak SIP and be willing to be a peer in the overlay. 
>
>Am I missing something? 
>
>Regards
>JiangXingFeng
>
>
>
>
>
>

---

From: Philip Matthews <[email-masked]>
Date: Fri, 15 Jun 2007 04:32:30 -0400

> interface or something similar).

Retrieving your buddy list is something that an ordinary SIP UA also  
wants to do,
so I don't think that P2PSIP should define a different way to do this  
without
a very good reason. I know almost nothing about XCAP, but if that is  
considered
the right way to do this on an ordinary SIP UA, then a P2PSIP peer  
that is acting
as a proxy should support this method of retrieving buddy lists.

Hence, I don't see this as an argument for a client protocol that is  
distinct from
what an ordinary SIP UA would implement.

- Philip

---

From: JiangXingFeng <[email-masked]>
Date: Fri, 15 Jun 2007 16:31:35 +0800

Hi, Marcin:
I fully agree with your point.
Regards
--
Jiang XingFeng

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, June 15, 2007 4:27 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Let's assume for a while that we have STUN/TURN servers that are external
to the
> overlay but may assist peers/SIP UA in NAT traversal. If we get rid of the
client
> protocol and clients how those servers can register to the DHT and
advertise their
> services? Are we planning to force all of network entities to implement a
SIP stack?

---

From: Philip Matthews <[email-masked]>
Date: Fri, 15 Jun 2007 04:46:31 -0400

But do you agree with Enrico too that everything Salman wants can be  
achieved by simply having
the mobile node act as an ordinary SIP UA?

- Philip

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

>>>> "concepts" in the document until someone argues why  one of  
>>>> these is
>>> of
>>>> particular interest.
>>>

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 15 Jun 2007 11:23:13 +0200

[email-masked] wrote:
> Let's assume for a while that we have STUN/TURN servers that are
> external to the overlay but may assist peers/SIP UA in NAT traversal. If
> we get rid of the client protocol and clients how those servers can
> register to the DHT and advertise their services? Are we planning to
> force all of network entities to implement a SIP stack?

We probably need a mechanism to allow nodes to register resources other 
than SIP URIs;  since such a mechanism will certainly be used by SIP UAs 
(why not in centralized or hybrid architectures too?) and since SIP 
already provides such a semantic, I'd really prefer to force network 
entities other than SIP UAs to implement the SIP REGISTER method (not a 
full stack) with the required TBD syntactic extensions, rather than 
force all nodes to implement a new protocol, or, even worse, to 
redundantly define a new protocol and then SIP extensions to avoid 
poor/weak/small SIP-aware devices to implement it!

---

From: Salman Abdul Baset <[email-masked]>
Date: Fri, 15 Jun 2007 06:34:47 -0400 (EDT)

> But do you agree with Enrico too that everything Salman wants can be achieved 
> by simply having

Indeed, it can be done but this assumes SIP as the peer protocol. Is this 
the best design?

Since we are P2PSIP WG, our goal is to design a peer protocol geared 
towards SIP. But as pointed by Jonathan Rosenberg a while back, this does 
not mean that we design a peer protocol which is so heavily geared towards 
SIP that it cannot be used for anything other than P2PSIP. We should not 
exclude the possibility that in the future some one can extend this 
protocol to applications such as p2p video streaming/on demand.

-salman

---

From: <[email-masked]>
Date: Fri, 15 Jun 2007 14:26:19 +0300

Enrico and Philip,

Let me clarify this:
Unmodified SIP UAs will communicate with the overlay using SIP. This
requires that some of the peers are collocated with SIP proxy/registrar
servers and implement SIP-DHT API. Not all of the peers and clients will
speak SIP. We did not make any decision regarding using SIP as the peer
protocol. Taking this into consideration many devices will not support
the SIP protocol. We have to allow them to put/get information to/from a
DHT. Widely deployed DHT networks such as PlanetLab use XML over HTTP
based protocols to implement PUT/GET method. We should allow developers
to extend their e.g. content sharing networks with real time
communication functionality provided by P2PSIP.  
   
Guys, please do not try to push SIP to all of the internet devices. If
you do so you will fail. Internet is not only about SIP! SIP is a
session initiation protocol. 

Marcin  

>From: ext Enrico Marocco [mailto:[email-masked]] 
>Sent: 15 June, 2007 12:23
>To: Matuszewski Marcin (Nokia-NRC/Helsinki)
>Cc: [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]
>active/passive peer terminology
>
>> external to the overlay but may assist peers/SIP UA in NAT 
>traversal. 
>> If we get rid of the client protocol and clients how those 
>servers can 
>We probably need a mechanism to allow nodes to register 
>resources other than SIP URIs;  since such a mechanism will 
>certainly be used by SIP UAs (why not in centralized or hybrid 
>architectures too?) and since SIP already provides such a 
>semantic, I'd really prefer to force network entities other 
>than SIP UAs to implement the SIP REGISTER method (not a full 
>stack) with the required TBD syntactic extensions, rather than 
>force all nodes to implement a new protocol, or, even worse, 
>to redundantly define a new protocol and then SIP extensions 
>to avoid poor/weak/small SIP-aware devices to implement it!
>
>--
>Ciao,
>Enrico
>

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 15 Jun 2007 14:17:58 +0200

Salman Abdul Baset wrote:
> Indeed, it can be done but this assumes SIP as the peer protocol. Is 
> this the best design?

Wait, wait wait.  The fact that clients speak SIP with peers doesn't 
imply at all that the peer protocol is SIP.

---

From: Enrico Marocco <[email-masked]>
Date: Fri, 15 Jun 2007 14:30:04 +0200

> communication functionality provided by P2PSIP.  

No, really, neither Philip nor I are proposing or pushing for SIP as the 
peer protocol.  The problem is just to understand if there is real need 
for a _client_ protocol other than SIP, assuming that SIP will be 
supported anyway to let non-p2p clients to use the overlay, or if we can 
get rid of it (or, in other words, if we can say that the _client_ 
protocol is SIP).

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 15 Jun 2007 09:53:57 -0400

<as individual>

I think we can stomp this one hard.

I think that, subject to someone coming up with a use case, the term
“client” is reserved for a SIP UA and nothing else.

There were several attempts to define a client that wasn’t a SIP UA, but no
one came up with a use case.
We decided to leave the door open for a use case.
No one has presented such.

Therefore, at least until someone does, the word “client” means a SIP UA.
We use the term "proxy peer" for the "gateway" you discuss below.

We continue to debate the notion that there may be some variation in "peers"
(we don't yet agree on terminology for what is a peer) that usually have
some variation on storage or network connectivity.

Personally, I think attempts to work around limitations in storage capacity
are often fruitless unless we're talking gigabytes.  I don't think we are.

Sometimes, we do need to be concerned with network bandwidth.  I'm not so
sure we are in this case.

I think that means that our choice for DHT needs to be reasonably efficient
in storage and bandwidth, but I doubt that is a revelation to anyone.  It
would be fascinating to me to have someone take Chord, or one of the other
DHTs, scale it up to a typical mobile network size, and figure out what each
handset needs in storage and bandwidth to be a fully p2psip system.  My gut
tells me it works.

We're stuck with the NAT issue; there is no getting around that.

I'd like to have more discussion on the above.  Do we really, truly have to
worry about peers who can't store?  Are we conflating the peers that can't
accept inbound from the peers that can't store -- that is, do we assume a
peer behind a NAT can't store?  Is that an appropriate assumption?

What ARE the storage requirements we are talking about?  Probably, there is
a tradeoff between the size of the store and the bandwidth needed.  Is that
actually relevant?

Brian

________________________________________
From: Greger V. Teigre [mailto:[email-masked]] 
Sent: Friday, June 15, 2007 2:52 AM
To: Enrico Marocco
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] Concepts document: proposalfor active/passive
peerterminology

I'm struggling a bit with an underlying issue that seems to only be
implicitly addressed (or I confuse things up).  To me it looks like people
are talking about two different types of clients without not always
specifying explicitly when they talk about which. I think all agree that the
"client" does not have full peer capabilities. However, such a client can be
aware of the overlay (as in routing or having some storage capability) and
as such participate in the overlay as a "lesser peer" or it can be ignorant
of the overlay, except that it knows that some entity offers GET/PUT. So, it
needs to have a full peer, which acts as a "gateway" into the overlay.

So, a first decision would be to decide whether a "lesser peer" should be
supported or if only access through a "gateway" should be allowed. A second
decision would be whether SIP should be used for communication between
client and "gateway peer" or some other client protocol.
g-)

Enrico Marocco wrote: 
Spencer Dawkins wrote: 

As far as I recall, the only credible use case which justifies the existence
of the "client" concept is that where a "non contributing" node wants to
store/retrieve in the overlay something which can't be encoded in SIP
(REGISTER?) messages (e.g. public keys, VM records...). 
Since such functionalities are not required to realize what the group has
been chartered for (are they?) and perhaps they could be used in centralized
environments too, well... I personally hope that it _is_ happening and that
we get rid of "clients" before the next meeting. 

________________________________________

---

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

I am actually quite sympathetic to the argument that P2PSIP should  
not just be about SIP.
I do not think that SIP will be the only protocol used inside the  
overlay, and I now think
that the peer protocol should be something other than SIP.

But in your last few messages, you two seem to be proposing something  
different.
It seems that you want the Distributed Database inside a P2PSIP  
overlay to be used for
non-SIP-related data, and for this non-SIP-related data to be  
accessible via Puts/Gets
from outside the overlay.

I think this is a very interesting idea, but this is a new direction  
that I believe has not been suggested before.

And I agree that supporting this strongly suggests that there should  
be a "database access" protocol
that is distinct from SIP.

- Philip

---

From: Dean Willis <[email-masked]>
Date: Fri, 15 Jun 2007 12:50:39 -0500

On Jun 15, 2007, at 3:27 AM, <[email-masked]>  
<[email-masked]> wrote:

> traversal. If we get rid of the client protocol and clients how  
> those servers can register to the DHT and advertise their services?  
> Are we planning to force all of network entities to implement a SIP  
> stack?
>

well, if SIP is our P2P protocol, as in dSIP, then yes, we are  
planning to force all network entities that offer services to the  
overlay to either have a SIP stack or some other interface to an  
entity that does have a SIP Stack and can inform the overlay about  
those services.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 15 Jun 2007 12:56:50 -0500

> handset needs in storage and bandwidth to be a fully p2psip  

Having recently seen a enormous data bill for light reading of mail  
on a Treo connected to a US GSM network, my gut tells me it might  
work but I don't want to pay for it. What part of $10 per megabyte do  
you not understand?

--
Dean

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 15 Jun 2007 21:07:16 -0700

> I am actually quite sympathetic to the argument that P2PSIP should  

Agree

There is a lot of substance for both (1) the "client" argument and also
(2) the "database" argument in the I-D that I recommend reading:

> be a "database access" protocol that is distinct from SIP.

Agree

As for the recent discussions, there is a lot of substance for both (1)
the "client" argument and also (2) the "database" argument in the I-D
that I recommend reading:

http://tools.ietf.org/id/draft-singh-p2p-sip-01.txt 

I already regret going on vacation all next week and missing the fun :-)

Thanks, Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Friday, June 15, 2007 5:11 PM
To: [email-masked]> <[email-masked]; Salman
Abdul Baset
Cc: P2PSIP Mailing List

- Philip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 15 Jun 2007 21:10:29 -0700

>I don't get why one should consider it a

For database functions and even for invoking the setup of a multicast
tree.

Henry

-----Original Message-----
From: Enrico Marocco [mailto:[email-masked]] 
Sent: Thursday, June 14, 2007 9:11 PM
To: Salman Abdul Baset
Cc: Henry Sinnreich; P2PSIP Mailing List
Subject: Re: [P2PSIP] Concepts document: proposal for active/passive
peer terminology

I agree on this too.

-- 
Ciao,
Enrico

---

From: Enrico Marocco <[email-masked]>
Date: Sat, 16 Jun 2007 09:07:44 +0200

> For database functions and even for invoking the setup of a multicast

Yeah, that's definitely something hard to achieve with SIP.  I don't
know if advanced data management and multicast are what the group should
focus on, at least in the beginning, but, if so, they certainly
constitute a good use case to justify clients' existence.

---

From: "Greger V. Teigre" <[email-masked]>
Date: Sun, 17 Jun 2007 10:47:05 +0200

I have a use case I'm struggling to map onto the various terms, and I'm 
also not sure where this working groups scope ends:
Let's say we have a regular 3261 SIP proxy. It wants to proxy requests 
into a number of overlays. Let's assume that AORs are distributed 
according to their domain (and AORs with the same domain name cannot be 
registered in several overlays).

We can then implement the contact between the proxy's domain(s) and the 
overlays in (at least) two ways:

a. Forward an INVITE into the overlay and wait for the result

b. Lookup the AOR in the overlay before proxying the INVITE and make 
routing decision based on the response

a does not require any coding in existing SIP proxyies, while b requires 
the SIP proxy to implement some sort of lookup mechanism into the 
overlay(s), either by being a peer in each overlay or by contacting a 
"proxy peer" (or is it "adapter peer"?) using some sort of data access 
protocol.

If we add the possibility of AORs from the same domain being registered 
in several overlays or if we want the proxy to route (or not) based on 
presence, we really need to do b.

I certainly don't want the data access protocol aka client protocol to 
be SIP, because I would then get a SIP message back that is really not 
part of initial INVITE transaction (or if it does not have the same 
transaction id, my proxy needs to be a UAC). The XML-RPC Get method 
described in http://tools.ietf.org/id/draft-singh-p2p-sip-01.txt seems 
more promising. And btw, the alternative, requiring a SIP proxy to be a 
peer in every overlay it wants to forward requests to sounds like the 
best way to stop that kind of communication from being done. (a 
side-note: from a SIP proxy implementation perspective, it is clearly a 
preference not having to implement a special standalone local query node 
that will registers as a peer and then offer a proprietary lookup 
interface to the proxy)

Finally, if we assume some kind of meta-lookup across overlays, we may 
be better off, but this is starting to feel a bit enum'ish to me...
g-)

Brian Rosen wrote:
> https://www1.ietf.org/mailman/listinfo/

---

From: JiangXingFeng <[email-masked]>
Date: Mon, 18 Jun 2007 10:16:53 +0800

My two cents...
Other than client and peer, there are some nodes having some other service
which would be helpful for the communication in the overlay, For example,
STUN or STUN relay service. At the same time, these service providers MAY
not speak SIP.

How do we decide the role of this kind of nodes? client or peer? If we treat
them as clients, it SHOULD have access mechanism to the overlay to put their
service so that  other peers or clients know where they are. If we treat
them as peers, it could use GET/PUT operations of peer protocol to achieve
this. But one important work of these nodes as a peer is to maintain the
overlay. If it is a peer and service other nodes may make it not stable,
hence influence the stability of the overlay. 
So we should not confine the location where these kinds of nodes lie. Client
role other ordinary SIP UA and client protocol other than SIP protocol MAY
be helpful. 

Regards!
--
Jiang XingFeng

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Friday, June 15, 2007 9:54 PM
> To: 'Greger V. Teigre'; 'Enrico Marocco'
for
> As far as I recall, the only credible use case which justifies the
existence

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 25 Jun 2007 10:38:48 -0700

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:
> Peer-ID? In otherwords, are they part of the overlay at all? If so,
for
> most

> contributing? If joining the overlay (in the sense that we have a
PeerID

I think we distinguish based on the service advertisements from the
peer.

--
Dean

---

From: Alan Johnston <[email-masked]>
Date: Tue, 26 Jun 2007 18:05:04 -0500

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:
>> 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
>   
>> DHTs, how do we allow you to be in the overlay and not store resources
>>     
> (not
>   
>> 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
>   
>> we route traffic) doesn't require me to store, I could offer no
>>     
> services
>
>> 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?
>

---

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 26 Jun 2007 19:25:44 -0400

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

> who contribute the least to the overlay also get the lowest performance

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: <[email-masked]>
Date: Wed, 27 Jun 2007 10:32:49 +0300

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?

		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:
		> From: Dean Willis [mailto:[email-masked] ]
active/passive

---

From: "David Barrett" <[email-masked]>
Date: Wed, 27 Jun 2007 10:05:37 -0700

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?

 

Thanks.

Eunsoo

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 27 Jun 2007 13:38:32 -0700

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.

-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: "David Barrett" <[email-masked]>
Date: Wed, 27 Jun 2007 15:41:33 -0700

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?

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

Power = A + nB

-david 

  _____  

Hi,

Marcin

  _____  

 

Thanks.

Eunsoo

---

From: Philip Matthews <[email-masked]>
Date: Wed, 27 Jun 2007 10:56:42 -0400

On 26-Jun-07, at 19:25 , Eunsoo Shim 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.

In the case of Chord, though Chord specifies a connection pattern  
based on powers of two, the search and routing algorithm will still  
work with fewer connections. However, the efficiency of the search  
and routing algorithm will decrease. If just ONE peer does this, the  
efficiency will not decrease greatly, but if all do, then it will.

> introducing these various levels of participation.

There is a chance that we might need to do both.

- Philip

---

From: <[email-masked]>
Date: Thu, 28 Jun 2007 14:57:55 +0300

Hi David,
 
It is more complex that your formula. The problem is with constant background traffic that keeps a radio interface on. There are differences between cellular and WLAN interfaces. The cellular interfaces are more optimized for idle state than the WLAN. I cannot send you a link to a document about power management in mobile peer-to-peer networks but two guys from my team are writing a paper about this topic. I will send the paper to the mailing list when it is accepted to a conference.
 
For now I can tell that constant background traffic may reduce the battery life to couple of hours.
 
I would appreciate any reference to a document presenting a traffic model in P2PSIP networks. Are you aware of such a document?
 
Marcin   

	From: ext David Barrett [mailto:[email-masked]] 
	Sent: 27 June, 2007 20:06
	To: Matuszewski Marcin (Nokia-NRC/Helsinki); [email-masked]; [email-masked]
	Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Subject: RE: [P2PSIP] do we need a client protocol?

	Power = A + nB

	-david 

	Hi,

	Marcin

		

			 

		
		
		Thanks.
		
		Eunsoo