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

From: "Michal Giermasinski" <[email-masked]>
Date: Mon, 9 Jul 2007 23:36:35 +0200

Hi Marc, David!

There is also another _commercial_ issue that is probably worth to remember.
When you "attach" the overlay and you become an active peer in message
routing, mobile device must take care of messages that are not addressed to
it. Currently most of users use GPRS-like access to the internet and telco
operators charge them on the amount of packets basis.

This is an issue that users may not be happy with. If you have let say
unlimited access to the internet you can make use of P2PPeerProtocol and
play the role of regular peer in the overlay. You can put some storege,
message routing actions to the overlay.
But if a user suffer from his bills while he would like to take some
advantages from p2pSip network there must be some way to help him. This is
in my oppinion one of the reasons that there should be a client protocol
defined.

Well, there is also a problem that most of users would like just to take
advantages from the access to the network than to play some serving roles.
That's the reason why users running peer protocol must be favoured from
those using client protocol.

Do you see any possibilities of such favouring?

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

---

From: <[email-masked]>
Date: Tue, 10 Jul 2007 12:51:08 +0300

Hi Michal,
 
You are right: charging and battery life are very important issues from
the end user perspective. As you said most of mobile phone users do not
enjoy flat rate subscriptions. They have to pay for every bit sent over
the air interface (received and sent). 
 
Besides many mobile phones are behind firewalls (don't mention NATs). In
order to be reachable they have send keepalives to some proxy/relay/etc.
In addition they would have to maintain DHT, forward search queries,
respond to GET/PUT requests for P2PSIP resource (user) records they are
responsible for. Thus, we would require mobile phone users to pay for
"only God knows what" traffic and recharge their mobile phones much more
frequently.
 
Yes there is some percentage of mobile phone users who would do that but
if we are targeting the mass market we need to consider those issues (at
least now, things may change in the future).
 
According to my quick study of 100 mobile phone users, it seems that we
should expect even higher rate of free riders in mobile P2P
applications.  
 
Marcin

________________________________

	From: ext Michal Giermasinski
[mailto:[email-masked]] 
	Sent: 10 July, 2007 00:37
	To: [email-masked]; Willekens Marc (NSN - BE/Belgium -
MiniMD)
	Cc: [email-masked]
	Subject: RE: [P2PSIP] do we need a client protocol?

	Hi Marc, David!
	 
	There is also another _commercial_ issue that is probably worth
to remember. When you "attach" the overlay and you become an active peer
in message routing, mobile device must take care of messages that are
not addressed to it. Currently most of users use GPRS-like access to the
internet and telco operators charge them on the amount of packets basis.

	This is an issue that users may not be happy with. If you have
let say unlimited access to the internet you can make use of
P2PPeerProtocol and play the role of regular peer in the overlay. You
can put some storege, message routing actions to the overlay. 
	But if a user suffer from his bills while he would like to take
some advantages from p2pSip network there must be some way to help him.
This is in my oppinion one of the reasons that there should be a client
protocol defined. 
	 
	Well, there is also a problem that most of users would like just
to take advantages from the access to the network than to play some
serving roles. That's the reason why users running peer protocol must be
favoured from those using client protocol. 

	Best regards
	Michal

---

From: "Wei Gengyu" <[email-masked]>
Date: Tue, 10 Jul 2007 21:55:07 +0800

Hi, 

If the problems were really considered in this way, perhaps there are some other situations:
1. some mobile users have fixed fee per month, so they do not care the amount of traffic.
2. some mobile users offen use adaptor connecting to power supply in office or home, so they do not care battery. 
3. some users may forward their mobile call to a fixed ISDN terminal, whether the participant will be treated as peer or client without battery or bandwidth limitation?
   In this case, the service capability problem may occurs due to mobile user attributes or ISDN user attributes.
   (Someone in the list ever metioned service capabiliy problem).
4. investigation of 100 users is not sufficient, as one mobile carrier here have more than 20,000,000 users. 

If you try, you could list many problems in other situations.

However, my suggestion is that we should not consider them in this stage.
At this begining stage, P2PSIP may follow the KISS principle, i.e. keep it simple and stupid.

Regards, 

Gengyu
  ----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] ; [email-masked] ; [email-masked] 
  Cc: [email-masked] 
  Sent: Tuesday, July 10, 2007 5:51 PM
  Subject: RE: [P2PSIP] do we need a client protocol?

  Hi Michal,

  You are right: charging and battery life are very important issues from the end user perspective. As you said most of mobile phone users do not enjoy flat rate subscriptions. They have to pay for every bit sent over the air interface (received and sent). 

  Besides many mobile phones are behind firewalls (don't mention NATs). In order to be reachable they have send keepalives to some proxy/relay/etc. In addition they would have to maintain DHT, forward search queries, respond to GET/PUT requests for P2PSIP resource (user) records they are responsible for. Thus, we would require mobile phone users to pay for "only God knows what" traffic and recharge their mobile phones much more frequently.

  Yes there is some percentage of mobile phone users who would do that but if we are targeting the mass market we need to consider those issues (at least now, things may change in the future).

  According to my quick study of 100 mobile phone users, it seems that we should expect even higher rate of free riders in mobile P2P applications.  

  Marcin

----------------------------------------------------------------------------
    From: ext Michal Giermasinski [mailto:[email-masked]] 
    Sent: 10 July, 2007 00:37
    To: [email-masked]; Willekens Marc (NSN - BE/Belgium - MiniMD)
    Cc: [email-masked]
    Subject: RE: [P2PSIP] do we need a client protocol?

    Hi Marc, David!

    There is also another _commercial_ issue that is probably worth to remember. When you "attach" the overlay and you become an active peer in message routing, mobile device must take care of messages that are not addressed to it. Currently most of users use GPRS-like access to the internet and telco operators charge them on the amount of packets basis. 

    This is an issue that users may not be happy with. If you have let say unlimited access to the internet you can make use of P2PPeerProtocol and play the role of regular peer in the overlay. You can put some storege, message routing actions to the overlay. 
    But if a user suffer from his bills while he would like to take some advantages from p2pSip network there must be some way to help him. This is in my oppinion one of the reasons that there should be a client protocol defined. 

    Well, there is also a problem that most of users would like just to take advantages from the access to the network than to play some serving roles. That's the reason why users running peer protocol must be favoured from those using client protocol. 

    Best regards
    Michal

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

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 10 Jul 2007 10:10:15 -0400

I think another question to ask is do we really need a client protocol
for P2P*SIP*?

I can see the many arguments that for other things than SIP using the
overlay, they may want to be able to get information and not have to
SIP, but from a charter perspective, we are only chartered to do P2P
specifically for SIP, and are supposed to keep it as simple as
possible while meeting that goal. I think people can agree that
getting a client protocol will eventually be a good goal, to enable
other applications, but our immediate goal needs to be a system for
P2P, SIP-based communications.

So getting back to the question Brian Rosen raised in Prauge:

Can anyone find a reason we need a client protocol for *SIP* using P2P?

So for example, a mobile phone (which likely has SIP on it if it is
IMS) -- can we find reasons that it won't work using just SIP as the
client protocol for SIP functions (calls, presence, conference,
whatever?)

We know there are lots of non-SIP things we can do if we have a client
protocol, but if we determine we don't need it to make SIP work, I
would agree with Wei and try to keep it simple for now. Assuming the
client protocol is a subset of the peer, we can always add it later
and keep our work as simple as possible for now.

David

On 7/10/07, Wei Gengyu <[email-masked]> wrote:
> 3. some users may forward their mobile call to a fixed ISDN terminal,
> whether the participant will be treated as peer or client without battery or
> bandwidth limitation?
> You are right: charging and battery life are very important issues from the
> end user perspective. As you said most of mobile phone users do not enjoy
> flat rate subscriptions. They have to pay for every bit sent over the air
> interface (received and sent).
>
> order to be reachable they have send keepalives to some proxy/relay/etc. In
> addition they would have to maintain DHT, forward search queries, respond to
> GET/PUT requests for P2PSIP resource (user) records they are responsible
> for. Thus, we would require mobile phone users to pay for "only God knows
> what" traffic and recharge their mobile phones much more frequently.
>
> Yes there is some percentage of mobile phone users who would do that but if
> we are targeting the mass market we need to consider those issues (at least
> now, things may change in the future).
>
> should expect even higher rate of free riders in mobile P2P applications.
>
> Marcin
>
>

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 10 Jul 2007 08:04:49 -0700

>we are only chartered to do P2P specifically for SIP, and are 
>supposed to keep it as simple as possible while meeting that goal.

This is just as true as the fact that the charter has to be useful to
the P2PSIP constituency and to end users.

Since ample arguments have been provided for the client protocol, why
not amend the charter?  

This is a good topic to take a hum on during the meeting (though I don't
believe majorities have anything to do with being right). 

Or maybe better elevate the issue to the IESG?

Failure to do so will only lead to the proliferation of incompatible
mobile devices that claim to support SIP or P2PSIP. The IESG must be
made aware of this.

Thanks, Henry

-----Original Message-----
From: David A. Bryan [mailto:[email-masked]] 
Sent: Tuesday, July 10, 2007 9:10 AM
To: Wei Gengyu
Cc: [email-masked]
Subject: Re: [P2PSIP] do we need a client protocol?

David

On 7/10/07, Wei Gengyu <[email-masked]> wrote:
>
>
> Hi,
>
> If the problems were really considered in this way, perhaps there are
some
> other situations:
> 2. some mobile users offen use adaptor connecting to power supply in
office
> or home, so they do not care battery.
>    In this case, the service capability problem may occurs due to
mobile
> user attributes or ISDN user attributes.
> 4. investigation of 100 users is not sufficient, as one mobile carrier
here
> have more than 20,000,000 users.
>
> At this begining stage, P2PSIP may follow the KISS principle, i.e.
keep it
> simple and stupid.
applications.

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

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Jul 2007 12:48:08 -0500

> Can anyone find a reason we need a client protocol for *SIP* using  

Clearly we have a reason to have some nodes that have lesser capacity  
and therefore offer fewer resources or services or whatever we might  
call them to the overlay. There's absolutely no doubt about this in  
my mind -- I think we can take it as a postulate.

So we're not asking the right question. Let's see if we can get some  
better questions:

1) Can the range of capacities of nodes be accommodated by one  
protocol that includes the ability to turn certain capabilities on  
and off (so that lesser-capable nodes could just not offer the things  
that are hard for them) or do we need an entirely different protocol  
for some class of nodes?

2) Assuming that we do need an entirely different protocol for the  
least-capable nodes, is there a requirement for the least-capable  
nodes to do anything that cannot already be done with SIP?

How could we make this decision?

If the peer protocol requires participation in a DHT, such that the  
node must store data hashed to its peer-ID, OR if the peer protocol  
requires message-passing capability in all peers, then we probably  
have a protocol that isn't suitable for nodes connected via 2.5G  
mobile or something similar. We can either fix this by 1) changing  
the protocol for all peers such that not all peers require these  
capabilities, or 2) using a different protocol for peers with these  
constraints.

The current concepts-and-terminology document allows for both  
approaches, but I'd very much like to come to consensus on a path  
here, because I think this is going to drive a lot of the work going  
forward.

--
Dean

---

From: <[email-masked]>
Date: Mon, 16 Jul 2007 21:31:48 +0300

Hi Dean,

I have not seen any solution that allows to turn off DHT maintenance,
message-passing, and data storage. From this reason I would prefer the
second option, but I am open for new proposals.
 
I would suggest to form a design team that would list a minimum set of
functionalities the client protocol must support. 

Marcin

>From: ext Dean Willis [mailto:[email-masked]] 
>Sent: 13 July, 2007 20:48
>To: David A. Bryan
>Cc: [email-masked]
>Subject: [P2PSIP] Restated question: do we need a client protocol?
>
>

---

From: Zheng Hewen <[email-masked]>
Date: Tue, 17 Jul 2007 09:41:04 +0800

Hi,

    Support.
    The second option is preferred from my viewpoint.
    The Client-Peer protocol, as which if it is called, is suggested that it would only maintain the relation between
P2PSIP-Client and its host P2PSIP-Peer and operate resource(Get/Put).

Best regards,
Hewen
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 2007?7?17? 2:32
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [P2PSIP] Restated question: do we need a client protocol?

Hi Dean,

I have not seen any solution that allows to turn off DHT maintenance, message-passing, and data storage. From this reason I
would prefer the second option, but I am open for new proposals.

I would suggest to form a design team that would list a minimum set of functionalities the client protocol must support.

Marcin

>call them to the overlay. There's absolutely no doubt about this in my
>mind -- I think we can take it as a postulate.
>
>1) Can the range of capacities of nodes be accommodated by one protocol
>that includes the ability to turn certain capabilities on and off (so
>that lesser-capable nodes could just not offer the things that are hard
>for them) or do we need an entirely different protocol for some class
>of nodes?
>
>least-capable nodes, is there a requirement for the least-capable nodes
>to do anything that cannot already be done with SIP?
>
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Jul 2007 22:30:04 -0400

inline.

Dean Willis wrote:
> for them) or do we need an entirely different protocol for some class of 
> nodes?
> 

I'm not sure I would classify it as something 'entirely different'; you 
could probably define it as a subset by just defining the usage of the 
read and write primitives.

That said, I personally think the client protocol is quite orthogonal to 
the peer protocol, and something where multiple protocols for this might 
make sense. In some uses, just having a SIP gateway function to provide 
a SIP interface makes sense. In other uses, something like a SOAP front 
end that exposes the DHT services to a web server makes sense. In other 
cases, using something that looks like the p2p protocol makes sense.

I view this a lot like the relationship between interior and exterior 
routing protocols in the Internet. In the backbone, everyone runs BGP. 
Its the one and only way to move stuff around. BGP is analagous to the 
peer protocol. But, each node participating in BGP can use a different 
interior routing protocol - RIP, OSPF, IS-IS, etc., which all serve to 
define the data that gets pushed into BGP, and defines what to do with 
the data that comes out. This is exactly our case here. DIfferent nodes 
in the same P2P network can have different client protocols, and it will 
all still work.

Considering the use case of a wireless client that wants to use the p2p 
network for SIP, the question is, is the p2p network SIP or should we 
define something else? The only difference I can think of is 
bootstrapping techniques, which may differ for p2p compared to regular SIP.

So, I am somewhat agnostic on whether we should define a separate client 
protocol or not. However, I feel strongly that it is orthogonal, and it 
is something we should keep out of the peer protocol. In the same way it 
is a mistake to view an interior routing protocol as something you 
design into your exterior routing protocol, so too should the client 
protocol be considered separate from the peer protocol. One way to 
illustrate this is to consider this scenario: if the peer protocol 
natively allows a node to be a client or a peer, what happens if all of 
the nodes elect to be clients? That would be bad.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com