Subject: [P2PSIP] To those interested in P2PSIP clients

From: Philip Matthews <[email-masked]>
Date: Thu, 15 Nov 2007 07:59:59 -0500

A word of advice to all those interested in P2PSIP clients:

Please write an internet-draft saying why you want clients. State the  
problem(s) that clients solve that peers do not.

More specifically:
* Describe a problem that you want to solve using clients.
* Present a convincing argument why that problem is interesting.
* Present a convincing argument why that problem cannot be solved  
using peers.

DO NOT go into the technical minutia of a client protocol. Just focus  
on convincing people that the problem is worthwhile solving and that  
some model of clients would be the best way to solve it.

The WG chairs requested this document at the Prague meeting in the  
spring, but I have yet to see it.

- Philip

PS. If someone thinks a recently posted draft meets this criteria,  
then I would appreciate a pointer to it.

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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 15 Nov 2007 10:25:59 -0500

Hmm, the need for the Client type has been said since November 2005.
Looks like the clock went back to the time in the group.
I may write a draft a couple of pages long if necessary.
Please see one of my previous emails I wrote today about this subject.
Thanks.

Eunsoo

-- 
Eunsoo

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 15 Nov 2007 07:27:49 -0800

Phil,

I completely agree with both you and Spencer and would like to add we
need a complete tool set and not work only with the one hammer (the
Concept paper).

I am troubled seeing only references to a single I-D as the ultimate
authority, no matter how good it is. 

There is a vast work on P2P out there (besides dominating Internet
traffic) that must be used by and reflected in P2PSIP.

Henry

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Thursday, November 15, 2007 5:00 AM
To: P2PSIP Mailing List
Subject: [P2PSIP] To those interested in P2PSIP clients

More specifically:

- Philip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 15 Nov 2007 10:39:24 -0800

Eunsoo,

>I may write a draft a couple of pages long if necessary.

This would be a great contribution!

Henry

-----Original Message-----
From: Eunsoo Shim [mailto:[email-masked]] 
Sent: Thursday, November 15, 2007 7:26 AM
To: Philip Matthews
Cc: P2PSIP Mailing List
Subject: Re: [P2PSIP] To those interested in P2PSIP clients

Eunsoo

-- 
Eunsoo

---

From: Zheng Hewen <[email-masked]>
Date: Fri, 16 Nov 2007 15:33:39 +0800

Hi,

     It's a great work. It seems that we need such a I-D ASAP.
     Hope to make some contribution.

Best regards,
Hewen

> Sent: 2007?11?15? 23:26

---

From: Zheng Hewen <[email-masked]>
Date: Fri, 16 Nov 2007 18:17:37 +0800

Hi,

    It seems that a formal I-D about P2PSIP clients requirement/character is important and desired.
    Are you ready to attend IETF70?
    I think that we can form a draft about P2PSIP client requirements/characters and make a presentation in Vancouver, do
you think so?
    I submitted an I-D about P2PSIP client protocol, you can get it from
http://www.p2psip.org/drafts/draft-zheng-p2psip-client-protocol-00.txt, any comment is appreciated.

Best regards,
Hewen

---

From: "Yao Wang" <[email-masked]>
Date: Fri, 23 Nov 2007 15:47:25 +0800

Hi, everyone.
	The attachment is a new I-D mainly talking about different types of nodes in P2PSIP. 
	This document is an attempt to classify different types of node in    peer-to-peer Session Initiation Protocol (P2PSIP).  Four possible types of nodes in P2PSIP are discussed based on two characters: whether it offers overlay-routing services and whether it offers storage functions.  The behaviors of each type of nodes and their possible necessities are analyzed.  This document is dedicated to be a reference for clarifying some controversial terms in P2PSIP working group, such as "client", "low-function peer", etc. 
	It is hoped that this document could help the WG to reach a rough consensus on the types of node within P2PSIP system and the characters of each type's behavior.

	Because the IETF Internet-Draft Submission is closed right now, I have to send it as attachment to this maillist. This document will be submitted to IETF as soon as IETF Internet-Draft Submission reopened. :)

Sincerely yours,
 
Yao Wang 
Mobile Life and New Media Lab, BUPT

-----Original Message-----
From: Philip Matthews [mailto:[email-masked]] 
Sent: Thursday, November 15, 2007 9:00 PM
To: P2PSIP Mailing List
Subject: [P2PSIP] To those interested in P2PSIP clients

More specifically:

- Philip

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 23 Nov 2007 10:52:32 -0500

The fundamental characteristics of Peers in DHT are the three things:
- Participates in overlay maintenance
- Provides routing service
- Provides storage service.

What do you mean by 'transport service'?

Thanks.

Eunsoo

-- 
Eunsoo

---

From: "lichun li" <[email-masked]>
Date: Sat, 24 Nov 2007 00:11:13 +0800

We reuse the terms in concept draft.
In concept draft:
"In P2PSIP, peers offer storage and transport
   services to allow the distributed database function and distributed
   transport function to be implemented."

On 11/23/07, Eunsoo Shim <[email-masked]> wrote:
> >         This document is an attempt to classify different types of node
> in    peer-to-peer Session Initiation Protocol (P2PSIP).  Four possible
> types of nodes in P2PSIP are discussed based on two characters: whether it
> offers overlay-routing services and whether it offers storage
> functions.  The behaviors of each type of nodes and their possible
> necessities are analyzed.  This document is dedicated to be a reference for
> clarifying some controversial terms in P2PSIP working group, such as
> "client", "low-function peer", etc.
> >         It is hoped that this document could help the WG to reach a
> rough consensus on the types of node within P2PSIP system and the characters
> of each type's behavior.
> >
> >         Because the IETF Internet-Draft Submission is closed right now,
> I have to send it as attachment to this maillist. This document will be
> submitted to IETF as soon as IETF Internet-Draft Submission reopened. :)
> >
> > Sincerely yours,
> >
> > Yao Wang

-- 
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, BUPT
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 23 Nov 2007 11:36:09 -0500

Then the transport service is another apsect of the 'routing service'.
It is like that we say the IP layer does routing (while an IP packet
carries a payload).
Somehow the definition of P2PSIP Peer in the concept draft does not
mention 'routing'.
I am going to suggest slight modification of the definition to other authors.

Back to your draft,  non-P2P Clients can certain exist. Actually a
device with just SIP UA is such a device.
But when we consider the overlay layer, such devices are irrelevant.
Nor they affect on the overlay protocol design. It just confuses the
discussion about node types for the overlay. I don't think such
devices should be considered as a type of node in the overlay.

Thanks.

Eunsoo

On Nov 23, 2007 11:11 AM, lichun li <[email-masked]> wrote:
> > On Nov 23, 2007 2:47 AM, Yao Wang < [email-masked]> wrote:
> > > Hi, everyone.
> offers overlay-routing services and whether it offers storage functions.
> The behaviors of each type of nodes and their possible necessities are
> analyzed.  This document is dedicated to be a reference for clarifying some
> controversial terms in P2PSIP working group, such as "client", "low-function
> peer", etc.
> > > From: Philip Matthews [mailto: [email-masked]]

-- 
Eunsoo

---

From: "lichun li" <[email-masked]>
Date: Sat, 24 Nov 2007 10:25:48 +0800

Please see inline.

> I am going to suggest slight modification of the definition to other authors.

I agree. Some explanations about these services should be given.

> devices should be considered as a type of node in the overlay.

I agree. This draft still needs modification. IMO, this type of node
is related to P2PSIP. And some SIP UAs may support some SIP extensions
for P2PSIP. So I think this type of node should be considered in WG.

-- 
Sincerely yours,

Lichun Li

---

From: Zheng Hewen <[email-masked]>
Date: Sat, 24 Nov 2007 10:58:35 +0800

Hi,

   Please see inline.

Best regards,
Hewen

> From: lichun li [mailto:[email-masked]]
> Sent: 2007?11?24? 10:26
> To: Eunsoo Shim
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] New I-D: different types of nodes in
> P2PSIP (was: Tothose interested in P2PSIP clients)
>
> Please see inline.
>
> I agree. This draft still needs modification. IMO, this type
> of node is related to P2PSIP. And some SIP UAs may support
> some SIP extensions for P2PSIP. So I think this type of node
> should be considered in WG.

[Hewen] There is already a consensus in IETF69 that the P2P layer should be distinct from the SIP layer, the last Concept
document (-v01) records it in Section 5.7. In fact, a device only with SIP UA is now regarded as a device irrelevant to P2P
layer.

> > > > >         The attachment is a new I-D mainly talking about
> > > > > different types
> > > of nodes in P2PSIP.
> > > > >         This document is an attempt to classify
> different types
> > > > > of node
> > > types of nodes in P2PSIP are discussed based on two characters:
> > > whether it offers overlay-routing services and whether it
> offers storage functions.
> > > The behaviors of each type of nodes and their possible
> necessities
> > > are analyzed.  This document is dedicated to be a reference for
> > > rough consensus on the types of node within P2PSIP system and the
> > > characters of each type's behavior.
> > > > >
> > > I have to send it as attachment to this maillist. This
> document will
> > > be submitted to IETF as soon as IETF Internet-Draft Submission
> > > reopened. :)
> > > > >
> > > > > Sincerely yours,
> > > > >
> > > > > Yao Wang
> > > > > * Present a convincing argument why that problem cannot be
> > > > > solved using peers.
> > > > >
> > > > > DO NOT go into the technical minutia of a client
> protocol. Just
> > > > > focus on convincing people that the problem is worthwhile
> > > > > solving and that some model of clients would be the
> best way to solve it.
> > > > >
> > > > > The WG chairs requested this document at the Prague
> meeting in
> > > > > the spring, but I have yet to see it.
> > > > >
> > > > > - Philip
> > > > >
> > > > > PS. If someone thinks a recently posted draft meets this
> > > > > criteria, then I would appreciate a pointer to it.
> > > > >

---

From: "lichun li" <[email-masked]>
Date: Sat, 24 Nov 2007 12:42:00 +0800

I also think the P2P layer should be distinct from the SIP layer.

-- 
Sincerely yours,

Lichun Li

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 23 Nov 2007 23:46:53 -0500

The node type 3 in the draft provides the storage service but the
routing service (transport service).
Could you describe a scenario where a device is not capable of
providing the routing service but capable of providing the storage
service?

Thanks.

Eunsoo

-- 
Eunsoo

---

From: "Wei Gengyu" <[email-masked]>
Date: Sat, 24 Nov 2007 17:00:56 +0800

Hi, all,

I have a question about P2P layer and Peer Identifier?

When saying P2P layer, are the entities at the layer identified by Peer Identifiers?
The Peer Identifier is used to identify the entity at application layer of Internet.
It seems that the Peer Identifier is generated by DHT.
Is there another  format of Peer Identifier which is readable, something like URI?

And the Peer Identifier should not be the same as the Host Identifier or Node Identifier in the Internet.
The P2P layer provides a service mapping the Peer Identifier to Host Identifier associated with a IP address or addresses. 

So, Peer Identifier is not a Host Identifier or IP address.

I would like to be educated.
It will be helpful for me to understand HIP.

Best regards, 

Gengyu

---

From: "lichun li" <[email-masked]>
Date: Mon, 26 Nov 2007 09:48:19 +0800

To provide storage service, a device should have enough disk space.
If the device doesn't support the routing algorithm, it is not capable of
providing the routing service. For example, a node only supporting Chord can
not be a peer in bamboo overlay.
If the device has poor connectivity, it's not suitable to provide routing
service. Maybe the device is behind NAT. Maybe the bandwidth is low. Maybe
the latency is high.

On 11/24/07, Eunsoo Shim <[email-masked]> wrote:
> > > [Hewen] There is already a consensus in IETF69 that the P2P layer
> should be distinct from the SIP layer, the last Concept
> > > document (-v01) records it in Section 5.7. In fact, a device only with
> SIP UA is now regarded as a device irrelevant to P2P
> > > layer.
> > >
> > >
> > > >
> > > > > Thanks.
> > > > >
> > > > > Eunsoo
> > > > >
> > > > >
> > > > >

-- 
Sincerely yours,

Lichun Li

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 25 Nov 2007 23:10:35 -0500

> not be a peer in bamboo overlay.

Hmm, so what you mean is that a device with enough HW resources and
good network conditions become a Client because it does not have the
right routing algorithm code. And such a device may provide the
storage service.

It seems it is a possible scenario. But still I am not sure how much
we gain having those Clients provide the storage service. Somehow I
feel it just adds complexity without much benefit. Do you see a
significant benefit from it?

> service. Maybe the device is behind NAT. Maybe the bandwidth is low. Maybe
Devices with these conditions won't be suitable to provide the storage service.

Thanks.

Eunsoo

> > On Nov 23, 2007 11:42 PM, lichun li < [email-masked]> wrote:
> > > On Nov 24, 2007 10:58 AM, Zheng Hewen < [email-masked]> wrote:
> > > > Hi,
> > > >
> > > >    Please see inline.
> > > >
> > > > Best regards,
> > > > Hewen
> > > >
> > > >
> > > > > On Nov 24, 2007 12:36 AM, Eunsoo Shim < [email-masked]> wrote:
> > > > > > > On 11/23/07, Eunsoo Shim < [email-masked]> wrote:
> > > > > > > > > From: Philip Matthews [mailto: [email-masked] ]

-- 
Eunsoo

---

From: "lichun li" <[email-masked]>
Date: Mon, 26 Nov 2007 14:19:28 +0800

> significant benefit from it?

The complexity can be reduced, if some messages and mechanisms in peer
protocol can be reused.
The benefit is enlarging the storage capacity of the system. Storing offline
messages, voicemail requires much disk space. Larger storage capacity
also enhances the resistibility to some kind of DoS attack.

I think the authors of
http://www.p2psip.org/drafts/draft-zheng-p2psip-client-protocol-00.txt also
have some good reasons.

> Devices with these conditions won't be suitable to provide the storage

A peer contacts many nodes. A client offering storage service only provide
storage service to its associated peer(s). Network condition requirement by
a peer is higher.
Network condition requirement: peer > client offering storage service >
normal client
I think at least the device behind NAT is suitable to offer storage service.

> > > > > > > Somehow the definition of P2PSIP Peer in the concept draft
> does
> > not
> > > > > > > mention 'routing'.
> > > > > > > > > >         It is hoped that this document could help the WG
> to
> > > > > > > > > > reach a
> > > > > > > > rough consensus on the types of node within P2PSIP system
> and
> > the
> > > > > > > > > >         Because the IETF Internet-Draft Submission is
> closed
> > > > > > > > > > right now,
> > > > > > > > > > Please write an internet-draft saying why you want
> clients.
> > > > > > > > > > State the

-- 
Sincerely yours,

Lichun Li

---

From: Zheng Hewen <[email-masked]>
Date: Mon, 26 Nov 2007 17:23:26 +0800

Hi,
 
   In my opinion, clients can provide storage service to its associated peer, but they do not store any DHT data, hence it
essentially is a kind of service over P2P network. P2PSIP peer/client protocol data operations (GET/PUT/REMOVE) can be
reused to implement the service; certainly other ways may be choices.
   For instance, peers in the overlay can store indices of files and clients store the files in real deployment, this design
reduces unwanted traffic into the overlay or/and enhances the ability to more stably and securely provide services.
Certainly, those are only considerations in the real deployment; it does not determine who is peer and who is client because
the decision is made by the operator.
   Any comment is appreciated.
 
Best regards,
Hewen

  _____  

From: lichun li [mailto:[email-masked]] 
Sent: 2007?11?26? 14:19
To: Eunsoo Shim
Cc: Zheng Hewen; P2PSIP Mailing List
Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothose interested in P2PSIP clients)

 

The complexity can be reduced, if some messages and mechanisms in peer protocol can be reused.
The benefit is enlarging the storage capacity of the system. Storing offline messages, voicemail requires much disk space.
Larger storage capacity also enhances the resistibility  to some kind of DoS attack.
 
I think the authors of http://www.p2psip.org/drafts/draft-zheng-p2psip-client-protocol-00.txt also have some good reasons.

A peer contacts many nodes. A client offering storage service only provide storage service to its associated peer(s).
Network condition requirement by a peer is higher. 
Network condition requirement: peer > client offering storage service > normal client
I think at least the device behind NAT is suitable to offer storage service.

Thanks.

Eunsoo

>
> On 11/24/07, Eunsoo Shim <  <mailto:[email-masked]> [email-masked]> wrote:
> > > > > From: lichun li [mailto:[email-masked]  <mailto:[email-masked]> ]
> > > > > Sent: 2007?11?24? 10:26
> > > > > To: Eunsoo Shim
> > > > > Cc: P2PSIP Mailing List
> > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip  <https://www1.ietf.org/mailman/listinfo/p2psip> 
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > > --
> > > > > > > > Eunsoo
> > > > > > > >
> > > > > [email-masked]  <mailto:[email-masked]> 

--
Eunsoo

-- 
Sincerely yours,

Lichun Li

---

From: <[email-masked]>
Date: Mon, 26 Nov 2007 12:15:05 +0200

>P2PSIP peer/client protocol data operations (GET/PUT/REMOVE) can be reused to implement the service; certainly other ways may be choices.

I would keep it external to the client protocol. If a peer decides to store data in another entity it may use any protocol to transfer the data, it does not have to be a client protocol. We should not invent yet another file transfer protocol.
 
Marcin 

________________________________

	From: ext Zheng Hewen [mailto:[email-masked]] 
	Sent: 26 November, 2007 11:23
	To: 'lichun li'; 'Eunsoo Shim'
	Cc: 'P2PSIP Mailing List'
	Subject: RE: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothoseinterested in P2PSIP clients)

	Hi,
	 
	   In my opinion, clients can provide storage service to its associated peer, but they do not store any DHT data, hence it essentially is a kind of service over P2P network. P2PSIP peer/client protocol data operations (GET/PUT/REMOVE) can be reused to implement the service; certainly other ways may be choices.
	   For instance, peers in the overlay can store indices of files and clients store the files in real deployment, this design reduces unwanted traffic into the overlay or/and enhances the ability to more stably and securely provide services. Certainly, those are only considerations in the real deployment; it does not determine who is peer and who is client because the decision is made by the operator.
	   Any comment is appreciated.
	 
	Best regards,
	Hewen

________________________________

		Sent: 2007年11月26日 14:19

			

		 

		The complexity can be reduced, if some messages and mechanisms in peer protocol can be reused.
		The benefit is enlarging the storage capacity of the system. Storing offline messages, voicemail requires much disk space. Larger storage capacity also enhances the resistibility  to some kind of DoS attack.

		A peer contacts many nodes. A client offering storage service only provide storage service to its associated peer(s). Network condition requirement by a peer is higher. 
		Network condition requirement: peer > client offering storage service > normal client
		I think at least the device behind NAT is suitable to offer storage service.

			Thanks.
			
			Eunsoo
			
			>
			> On 11/24/07, Eunsoo Shim < [email-masked] <mailto:[email-masked]> > wrote:
			> > > > > From: lichun li [mailto:[email-masked] ]
			> > > > > Sent: 2007?11?24? 10:26
			> > > > > To: Eunsoo Shim
			> > > > > Cc: P2PSIP Mailing List

			--
			Eunsoo

		-- 
		Sincerely yours,
		
		Lichun Li

---

From: "Wei Gengyu" <[email-masked]>
Date: Tue, 27 Nov 2007 15:55:33 +0800

Hi, all, 

I make the question concret.

From RFC 4423, we know that "the Host Identity Protocol (HIP), between the internetworking and transport layers"
So, we can draw a picture of HIP protocol layer in the Internet as follows:

      Application layer
     
      TCP/UDP
     
      HIP
     
      IP

 

How HIP used in the P2PSIP overlay?  We have seen two proposed in the I-Ds. 

The first one is in "draft-matthews-p2psip-hip-hop-00."  It depicts the protocol architecture of P2P layer in two places as follows: 

"Consider the architecture for a P2PSIP peer shown in Figure 1".

      SIP
     Other applications
     
      Distributed Database
     Distributed Database
     
      Distributed Transport

"Figure 4 shows the fundamental protocol layering in our proposal."

      SIP
     Other applications
     
      Distributed database
     Overlay maintenance
     
      TCPv6, UDPv6, TLS, etc.
     
      HIP or ESP
     
      UDPv4
     UDPv6
     
      IPv4
     IPv6

The second one is in "draft-hautakorpi-p2psip-with-hip-01.txt"

"The network protocol layering, in four distinct cases, is illustrated in Figure 3."(the following figure)

      HIP

     
      Peer protocol
     Peer protocol
     SIP & Data

      Transport protocol
     Transport protocol
     Transport protocol
     HIP
     
      ESP
     ESP
     ESP
     ESP
     
      UDP
     UDP
     UDP
     UDP
     
      IP
     IP
     IP
     IP

a)Initial HIP Base Exchange  b) Peer Protocol  c) SIP signaling and data  d) Subsequent HIP packets

So, there are some basic concepts that must be made clear.

1. what is P2P layer. Is it a overlay at the application layer of Internet or is it including several layers i.e., network, transport and application layers.

2. In draft-hautakorpi-p2psip-with-hip-01.txt, 

"Peers in a P2PSIP network need to have long-lived connections to other peers in the network, and HIP can be utilized to setup and maintain those connections." 

Why the HIP protocol is put over Peer protocol?

3. In "draft-matthews-p2psip-hip-hop-00",

"We discuss the functions of the P2P layer in such an architecture, and focus in on the Distributed Transport function - the function that allows a peer to exchange messages with any other peer in the overlay, even in the presence of NATs."

"We discuss how a complete P2PSIP architecture can be built around HIP, and contrast this approach with other approaches for implementing a P2P layer."

Please clarify which figure is the P2P layer even though I could infer that the P2P layer includes several layers in the context. 

4. In "draft-matthews-p2psip-hip-hop-00",

"Host Identities could be assigned to peers in at least two different ways. One way is for peers to generate their own public/private key pairs. Another way is to allocate them to peers, perhaps in    conjunction with a set of credentials, using a centralized allocation system."

What is Host Identities or identifier? What is Peer Identifier?

Are those identifiers at the same layer or not? 

Looking forward the reply.

Regards, 

Gengyu

----- Original Message ----- 
From: "Wei Gengyu" <[email-masked]>
To: "P2PSIP Mailing List" <[email-masked]>
Sent: Saturday, November 24, 2007 5:00 PM
Subject: [P2PSIP] P2P layer and Peer Identifier

>> On Nov 24, 2007 10:58 AM, Zheng Hewen <[email-masked]> wrote:

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

---

From: Philip Matthews <[email-masked]>
Date: Tue, 27 Nov 2007 08:30:42 -0500

On 27-Nov-07, at 02:55 , Wei Gengyu wrote:

> 1. what is P2P layer. Is it a overlay at the application layer of  
> Internet or is it including several layers i.e., network, transport  
> and application layers.

In draft-matthews-p2psip-hip-hop-00, the P2P layer was introduced to  
split this functionality from the SIP layer. At the time that draft  
was written, people were still arguing for a combined SIP + P2P  
layer. Since then, however, the WG has agreed that there will be at  
least two different layers.

> "Peers in a P2PSIP network need to have long-lived connections to  
> other peers in the network, and HIP can be utilized to setup and  
> maintain those connections."
>

HIP comes with its own signaling protocol. So the question is: what  
is the relationship between that protocol and the peer protocol. I  
can see four answers:
1) The Peer Protocol runs over HIP signaling.  This was the approach  
taken in draft-matthews-p2psip-hip-hop. This approach probably  
requires extensions to HIP, and a number of such extensions are  
proposed in that draft.
2) HIP signaling runs over the Peer Protocol.  This is the approach  
taken in draft-hautakorpi-p2psip-with-hip. By doing this, fewer  
extensions to HIP are required (perhaps none).
3) Features of HIP signaling are integrated into the Peer Protocol.  
This is the approach that I currently think is the most promising.  
draft-matthews-p2psip-id-loc hints at this approach, without any real  
details.
4) Features of the Peer Protocol are integrated into HIP. So far, no  
one is proposing this approach.

> "We discuss the functions of the P2P layer in such an architecture,  
> and focus in on the Distributed Transport function - the function  
> that allows a peer to exchange messages with any other peer in the  
> overlay, even in the presence of NATs."
>
> "We discuss how a complete P2PSIP architecture can be built around  
> HIP, and contrast this approach with other approaches for  
> implementing a P2P layer."
>
> Please clarify which figure is the P2P layer even though I could  
> infer that the P2P layer includes several layers in the context.

Yes. In draft-matthews-p2psip-hip-hop-00, the term "P2P layer" meant  
the combination of three protocols: Peer Protocol, HIP, and whatever  
transport protocol the application was using.

> "Host Identities could be assigned to peers in at least two  
> different ways. One way is for peers to generate their own public/ 
> private key pairs. Another way is to allocate them to peers,  
> perhaps in    conjunction with a set of credentials, using a  
> centralized allocation system."
>

A Host Identity is a concept from HIP. It is a unique identifier for  
a host in the Internet, and doesn't change even if the host changes  
its IP address(es).

A Peer Identifier is a concept from P2PSIP. It is a unique identifier  
for a peer in a specific overlay, It presumably also doesn't change  
if the peer changes its IP address(es).

One of the motivators behind trying to figure out the relationship  
between HIP and P2PSIP is that these two concepts seem very similar.

draft-matthews-p2psip-hip-hop proposed that the two concepts should  
be the same. However, there is now a debate on whether this would  
make overlays more vulnerable to the "Chosen Location" attack. Though  
I still wonder if this is really true, never-the-less I am starting  
to think that the two concepts are distinct (but related).

- Philip