Subject: Re: [P2PSIP] Roles

From: Dean Willis <[email-masked]>
Date: Mon, 18 Jun 2007 23:34:21 -0500

On Mar 22, 2007, at 8:51 AM, Henning Schulzrinne wrote:
> The notion of separation is that of making a decision and providing  
> a token. I used the bouncer model intentionally: The bouncer checks  
> your driver's license and makes sure that you are of legal age and  
> that you aren't on the establishment's black lists of unwanted  
> guests, and then stamps your palm. The bar tender "admits" you to  
> the bar by checking the stamp. In a P2P sense, the admission  
> function may check a node's reputation, consult black lists,  
> perform return routability checks, CAPTCHA/turing tests and other  
> checks, and then hands a token, such as a signature, verifying that  
> the new node has passed these tests. Naturally, we wouldn't specify  
> any of the details of the tests, but they are separable.

I'm struggling with integrating this into the concepts document.

As I see it, the "enrollment" process provides the token. Once you've  
enrolled, you have a a set of credentials that can be checked by any  
of the "bouncers" (aka admitting peers) and by any of the service  
providing peers (aka "bartenders") from whom you might request  
service. I think this model is quite completely provided for in the  
current draft of the concepts model.

So what am I missing?

--
Dean

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

---

From: "BOUCADAIR Mohamed RD-CORE-CAE" <[email-masked]>
Date: Tue, 19 Jun 2007 14:15:02 +0200

Dear authors,

Below some comments about your draft:

1- The design goal of XPP have already been tackled in IAX specification
protocol. Please refer to http://tools.ietf.org/id/draft-guy-iax-03.txt
In order to avoid redundant work. IAX  solves the problem of NAT
traversal in a native way. It is also a binary protocol which implements
reliability means because it is built upon UDP. Perhaps not all of IAX
features are required in the context of P2P..

2- If XPP supports means for NAT traversal why then you need ICE and
STUN? If this is required, I don't understand the motivation for this
specification. 

3- You state in section 1.2 "P2PP has many things in common with XPP;
mainly, it
   is binary and uses a very similar encoding for parameters based on
   type-length-value (TLV) fields.  However, it misses a mechanism for
   simultaneously initiating sessions, which is one of XPP's most
   important features"

Why not proposing that enhancement to authors of P2PP instead of
specifying a new protocol?

Cheers,
Med

---

From: Emil Ivov <[email-masked]>
Date: Tue, 19 Jun 2007 14:50:01 +0200

Hello Mohamed

(comments inline)

BOUCADAIR Mohamed RD-CORE-CAE wrote:
> traversal in a native way. 

Well not exactly. IAX handles both signaling and media transport
which means that it doesn't need to take care of dynamic NAT bindings. 
In other words it doesn't really have the problem of NAT traversal.

> It is also a binary protocol which implements

Thanks for the pointer. It might indeed be useful to borrow inspiration 
from IAX when dealing with transport problems that they have resolved. 
We'll keep this in mind.

> STUN? If this is required, I don't understand the motivation for this

ICE and STUN *are* the means that can be used during XPP session
negotiation to handle NAT traversal. XPP alone is simply being friendly 
to such mechanisms as it allows for simultaneous session establishment.

> specifying a new protocol?

Well actually, XPP is the outcome of the sipdht2 project 
(http://sipdht.sourceforge.net/sipdht2/). When we started sipdht2 p2pp 
was still in an early stage (it was called p2p-common at the time) so 
this explains the initial split. Both protocols have many similarities 
and they also have a few differences. Anyway, I agree that this is a 
reasonable suggestion so we are definitely interested in further 
discussing a possible synergy.

Cheers
Emil

---

From: "BOUCADAIR Mohamed RD-CORE-CAE" <[email-masked]>
Date: Tue, 19 Jun 2007 15:03:48 +0200

Thanks for your answers.

Just some clarifications regarding IAX, the NAT problem is avoided thanks to the following design choices:

- usage of a single UDP port (just like HTTP)
- Utilisation of application-based identifiers to uniquely distinguish sessions
- IAX does not carry any IP addresses inside its messages
- Once registration message is issued by a client, the server (or the remote peer) uses the source information to reply. The answer will be delivered whatever the type of intermediate NAT.

Cheers,
Med

-----Message d'origine-----
De : Emil Ivov [mailto:[email-masked]] 
Envoyé : mardi 19 juin 2007 14:50
À : BOUCADAIR Mohamed RD-CORE-CAE
Cc : [email-masked]
Objet : Re: [P2PSIP] COMMENTS on I-D ACTION:draft-marocco-p2psip-xpp-00.txt

Hello Mohamed

(comments inline)

BOUCADAIR Mohamed RD-CORE-CAE wrote:
> 1- The design goal of XPP have already been tackled in IAX 
> specification protocol. Please refer to 
> http://tools.ietf.org/id/draft-guy-iax-03.txt

Well not exactly. IAX handles both signaling and media transport which means that it doesn't need to take care of dynamic NAT bindings. 
In other words it doesn't really have the problem of NAT traversal.

> It is also a binary protocol which implements reliability means 
> because it is built upon UDP. Perhaps not all of IAX features are 
> required in the context of P2P..

Thanks for the pointer. It might indeed be useful to borrow inspiration from IAX when dealing with transport problems that they have resolved. 
We'll keep this in mind.

> STUN? If this is required, I don't understand the motivation for this 

ICE and STUN *are* the means that can be used during XPP session negotiation to handle NAT traversal. XPP alone is simply being friendly to such mechanisms as it allows for simultaneous session establishment.

> specifying a new protocol?

Well actually, XPP is the outcome of the sipdht2 project (http://sipdht.sourceforge.net/sipdht2/). When we started sipdht2 p2pp was still in an early stage (it was called p2p-common at the time) so this explains the initial split. Both protocols have many similarities and they also have a few differences. Anyway, I agree that this is a reasonable suggestion so we are definitely interested in further discussing a possible synergy.

Cheers
Emil

---

From: Philip Matthews <[email-masked]>
Date: Tue, 19 Jun 2007 09:40:17 -0400

On 19-Jun-07, at 09:03 , BOUCADAIR Mohamed RD-CORE-CAE wrote:

> - Once registration message is issued by a client, the server (or  
> the remote peer) uses the source information to reply. The answer  
> will be delivered whatever the type of intermediate NAT.
>
> Cheers,
> Med

I would just like to point out that first three of these design  
choice, though good, do not allow IAX or any other protocol to avoid  
the NAT traversal problem. They simply get rid of extra distractions.

Regarding the fourth, I don't understand this one. It sounds like the  
media flows via a proxy, but I cannot believe this.
However, I will point out that there are two general choices. Either  
(a) the media has to flow via the proxy, or (b) the endpoints have to  
do UDP hole punching (using a protocol like ICE) to get the media to  
flow directly between the two peers.

- Philip

---

From: Salman Abdul Baset <[email-masked]>
Date: Tue, 19 Jun 2007 17:13:24 -0400 (EDT)

> (http://sipdht.sourceforge.net/sipdht2/). When we started sipdht2 p2pp was 
> still in an early stage (it was called p2p-common at the time) so this 
> explains the initial split. Both protocols have many similarities and they 
> also have a few differences. Anyway, I agree that this is a reasonable 
> suggestion so we are definitely interested in further discussing a possible 
> synergy.

If I understand correctly, 'simultaneous connections' is the same as 
'parallel connections' which P2PP supports.

-s

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 20 Jun 2007 08:43:13 +0200

> 'parallel connections' which P2PP supports.

I don't think so.  "Simultaneous" is the establishment, the handshake,
not the connection; it means that, peers establishing a session, start
sending packets simultaneously.  P2PP doesn't have such a mechanism,
does it?

-- 
Ciao,
Enrico