Subject: [P2PSIP] Trying to grasp what we really are standardizing...

From: "Greger V. Teigre" <[email-masked]>
Date: Mon, 25 Jun 2007 12:00:05 +0200

It seems to me (based on the drafts) that this working group has set out 
to standardize too much. However, I may be unable to see the big picture 
after reading the drafts...

I'm trying to use a (simplistic) layered approach, please help me sort 
out my confusions...

The logical starting point for me is the pure SIP UA (already out 
there). It will (hopefully) support sip-outbound and ice.  It will thus 
expect to find a registrar, as well as a STUN and a STUN relay function. 
Using these mechanisms, the UA will happily REGISTER with the assigned 
registrar, establish the necessary sip-outbound flows and will negotiate 
using ice when setting up a dialog. 

For simplicity, let's say the registrar happens to be a P2PSIP peer 
physically residing on another device. This peer should have a SIP 
implementation, as well as a p2p implementation. This peer should be 
able to act as a registrar for the SIP UA, including ping-pongs, do 
routing, and offer STUN relay addresses when an INVITE goes through 
(contrary example, draft-marocco-p2psip-interwork-01 seems to indicate 
some p2psip-aware code in the SIP UA).  In my mind, the P2P layer should 
offer the SIP-part of the peer an API where messages can be routed and 
relay function data retrieved, (draft-baset-p2psip-p2pcommon-01 seems to 
be closest, but concerns a protocol on the wire) however, implementing 
the API in the SIP code should be a fairly simple one-to-one mapping.

The API should be standardized in this working group, so that any SIP 
implementor having implemented the P2PSIP API can plug in a new p2p 
implementation (or support several). These implementations could be 
different overlays or different libraries implementing the same 
overlays. Hopefully, all the various available p2p implementations will 
implement this API, thus ensuring that SIP UA implementations quickly 
will become p2p aware.

So far so good, NAT has been handled on the SIP layer for both signaling 
and media, and the only thing we need is an implementation of the P2PSIP 
API that realizes the API functions...

However, now I start to get a bit confused. We want to standardize to 
ensure interoperability. Well, with a well-designed P2PSIP API, we have 
come pretty far, I think. We have interoperability using all the SIP 
mechanisms, including 3263. SIP messages can flow across overlays on the 
SIP layer. So, what more do we want to ensure? That various 
implementations on the p2p layer can talk to each other? Why do we want 
that?  Won't we just freeze innovation because we are not able to create 
a protocol between the peers that is agnostic to hash tables etc? I know 
the charter says we should standardize the protocol between the peers, 
but I feel that SIP and p2p is mixed together too much and I just don't 
get it.

Ok, so people want interoperability between p2p peers, but I don't 
really see how we can avoid spending a lot of resources on just creating 
a default that probably quickly will be outdated?! (we're not 
standardizing a best practice that has emerged already)  And I don't 
really see what we gain (unless the ambition is to create a world-wide 
p2p network where also non-SIP can be transported...).

So, based on my lack of understanding of the above, pardon my lack of 
understanding on some other issues:
- How NAT is handled on the p2p layer should have nothing to do with the 
SIP layer.  One should be free to make any decision, right?
- Whether to use SIP, binary, or some text-based protocol (if to be 
standardized) should really be based on facts: what works most 
efficiently from a *protocol standpoint*? Let's not get confused by the 
fact that SIP will be transported on top of the p2p protocol.
- Choosing of transport-layer protocols: again, ignore SIP, what works?

Of course, as both the SIP and p2p layers must solve NAT traversal, it 
is easy to mix them together and yes, I'm open to the possibility of 
collapsing the layers for optimization reasons. But I don't think we are 
there yet. And I also think that through some separation, the p2p guys 
(I'm not one of them) and the SIP guys can concentrate on what they are 
good at. If we mix, only people who are experts on both can a) implement 
b) have an opinion.

Please,attack my arguments.
g-)

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

---

From: Enrico Marocco <[email-masked]>
Date: Mon, 25 Jun 2007 12:40:02 +0200

Greger V. Teigre wrote:
> some p2psip-aware code in the SIP UA).

Actually, open issue #3 in the draft acknowledges that sometimes such a
discovery must be done by peers on behalf of non p2p-aware UAs.  What we
wanted to stress is the fact that only some peers (proxy peers in the
draft) can effectively do 3263 routing; in certain scenarios, nodes with
limited connectivity can still become peers (it depends on the overlay
algorithm), but cannot send messages to nodes on the Internet.

We'll make it clearer in the next version.

-- 
Ciao,
Enrico

---

From: Philip Matthews <[email-masked]>
Date: Mon, 25 Jun 2007 09:06:45 -0400

On 25-Jun-07, at 06:00 , Greger V. Teigre wrote:
> So, based on my lack of understanding of the above, pardon my lack  
> of understanding on some other issues:
> - How NAT is handled on the p2p layer should have nothing to do  
> with the SIP layer.  One should be free to make any decision, right?

It seems to me that you are talking about a P2P layer architecture  
like the one described in
     draft-matthews-p2psip-hip-hop-00
which talks about a P2P layer that sits below the SIP layer and  
provides three main functions:
    1) Distributed Database
    2) Overlay Maintenance
    3) Distributed Transport (e.g., routing messages around the overlay)
Is this correct?

With the architecture above, I don't see how you can handle NAT  
traversal at the SIP layer for SIP signaling. The only proposal that  
I have seen that handles NAT traversal at the SIP layer for SIP  
signaling is dSIP, and dSIP does not have a separate P2P layer but  
does everything in SIP. If you are going to separate the P2P layer  
from the SIP layer, then I think you are pretty much forced to put  
NAT traversal logic in the P2P layer for both P2P messages and for  
SIP signaling. The only thing you could leave up at the SIP layer is  
NAT traversal for RTP packets.

- Philip

---

From: "Greger V. Teigre" <[email-masked]>
Date: Mon, 25 Jun 2007 16:02:08 +0200

Philip Matthews wrote:
>> - How NAT is handled on the p2p layer should have nothing to do with 
>> the SIP layer.  One should be free to make any decision, right?
>
Well, I didn't really take a position on the actual layering, I was just 
trying to look at the functions that must be presented to the pure SIP 
UA. Unless I'm completely mistaken, a pure SIP UA should be able to 
contact a SIP UA using the p2p overlay in a completely transparent 
fashion. Those two UAs, one registered with a SIP registrar (c/s), the 
other in a p2p overlay should be able to use ice to set up the dialog. 
If a relay is needed, it really doesn't matter if a server in the c/s 
domain offers the relay or if the p2p overlay offers the relay as a 
service (or maybe both and the best is chosen).

I would think that a pure SIP UA maybe could establish sip-outbound 
flows both to a SIP registrar (c/s) and to a peer in the overlay (acting 
as a registrar). This could enable emergency/disaster redundancy or even 
be useful for service providers.
> traversal at the SIP layer for SIP signaling. The only proposal that I 
> have seen that handles NAT traversal at the SIP layer for SIP 
> from the SIP layer, then I think you are pretty much forced to put NAT 
> traversal logic in the P2P layer for both P2P messages and for SIP 
> signaling. The only thing you could leave up at the SIP layer is NAT 
> traversal for RTP packets.
My point is that NAT-traversal for SIP and NAT-traversal on the P2P 
layer really is logically two separate things, and they should be 
analyzed separately. It may well be that the underlying p2p layer can 
offer the SIP layer a non-NATed routing environment (indeed, it is 
probably desirable), but in theory the p2p layer can tackle it's own 
signaling NAT traversal without offering the SIP layer a non-NATed 
routing environment (leaving private IP addresses in SIP messages).
g-)

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Mon, 25 Jun 2007 10:11:30 -0400

Greger,

For your example, where you have a "pure SIP" UA contacting a fixed
location registrar that happens to be backed by a P2PSIP overlay, I
think you're right that you can regard the NAT traversal problems as
distinct.  But I think this comes out of the assumption that the
registrar has an unfiltered public IP address such as any conventional
registrar would have.  This is one use case for P2PSIP, looking at
Section 3 of p2psip-concepts, you assume that the world consists of
SIP UAs (behind NATs) and Proxy Peers (not behind NATs).  But for
other use cases, such as with the UA Peers that are behind NATs, you
can't make the assumption that SIP outbound NAT traversal will work.
There is no registrar or proxy to contact.  In this case, the overlay
is providing connectivity between the peers, and it makes sense (to
me) to use the overlay in some fashion to establish SIP sessions
between different UA peers.  At this point we've seen several
proposals for how to accomplish this, but there's a fairly common
thread that the overlay already has a means of performing NAT
traversal that the SIP messages leverage.

Bruce

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 25 Jun 2007 10:22:46 -0400

I think there are several ways the NAT functions can be handled, just
a few I have seen proposed are:

* P2P layer == SIP layer, both use SIP functions to traverse NATs
* P2P layer does its own NAT traversal, and is used to either
negotiate openings or encapsulates the SIP layer traffic
* SIP layer does the NAT traversal, and session and NAT traversal of
the P2P is negotiated there (perhaps it is listed as an SDP stream)
* The two layers are completely independent

Also people have discussed if ICE is appropriate for the P2P protocol
negotiation, assuming it is not SIP (no one is seriously (at least I
hope not) proposing inventing something other than ICE for the NAT
traversal on the SIP side...)

I agree that we should probably analyze the two NAT traversal
mechanisms seperately, but I personally think we will find ICE is the
answer in each case, and I really don't like the idea of having to
implement two different NAT traversal techniques and do NAT traversal
two times for the two protocols. This group is about making a protocol
for P2P *specifically* for SIP, we don't need to go out our way to
make it function in other cases, so I think reuse of ICE makes the
most sense. There may be an IETF group to do more generic P2P someday
(I hope so), and hopefully it will grow from our work, but this group
is sort of a baby-step that direction for the IETF -- try to see if a
group can make a P2P protocol work in a narrow problem space like P2P
specifically for SIP -- before deciding about more general P2P
protocols.

As far as why we are talking about standardizing the DHT between
peers, I'll give you my take. The IETF goal is to allow
implementations from different vendors to work together
interchangably. The IETF doesn't define code APIs, they standardize
the protocols that go over the wire. It isn't about an API that every
SIP UA can implement to call a P2P library, it is about different P2P
devices from different vendors, scattered across the internet or
within an organization being able work together to form a serverless
environment. To think similarly, we aren't saying "here is a set of
code hooks a web browser can use, and underneath developers can write
a library to access "their" proprietery web".  Instead, we are making
sure that all the P2PSIP devices across the internet, regardless of
vendor, can be interchangably connected into a P2P overlay and work
together.

David

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

---

From: "Wei Gengyu" <[email-masked]>
Date: Tue, 26 Jun 2007 00:14:03 +0800

Hi, 

If P2PSIP overlay is intended to convey SIP(3261,3263) messages, there would be some contradictions.
SIP(3261,3263) in nature is based on client/server architecture. But P2P overlay is different.

So, P2PSIP overlay will transfer session setup (initiation) messages on peer to peer overlay 
while it can be proxy of SIP (3261 and 3263) just for compatibility.
I  do not agree to make SIP over P2P as a main purpose. 

P2PSIP should have its own architecture to have session setup function and to process NAT  traversal or firewall. 

Regards,

Gengyu

---

From: Philip Matthews <[email-masked]>
Date: Mon, 25 Jun 2007 13:02:32 -0400

I agree with Bruce.
- Philip

On 25-Jun-07, at 10:11 , Bruce Lowekamp wrote:

>> with

---

From: "Greger V. Teigre" <[email-masked]>
Date: Wed, 27 Jun 2007 09:50:03 +0200

Hi Bruce,
Yes, I don't think we disagree on "to use the overlay in some fashion to 
establish SIP sessions between different UA peers".

My post was triggered by a concern over multiple suggested approaches 
taking different cuts at creating layers/abstraction, but without any 
overarching understanding of what the different logical layers really 
are. I started at (what I think is) the top-most layer, i.e a pure SIP 
UA using the overlay.  I also found it useful to logically separate the 
SIP UA function of a p2psip client and the p2p function in the client. 
 From a software design point of view, I would like to reuse any SIP 
code and keep it maintained separately from the p2p code, so it just 
makes sense to think that way.

I also think that approaching the problem that way may provide some 
insights that easier can be discussed independent of approach taken 
(i.e. dSIP, hip-hop, xpp). I believe that analyzing in layers makes 
sense before you start joining functions and that doing so is not only 
an academic exercise. For example, you write "But for other use cases, 
such as with the UA Peers that are behind NATs, you can't make the 
assumption that SIP outbound NAT traversal will work."
This statement is obviously based on several assumptions, the most 
important one about a tight integration of a peer UA and a SIP UA. If 
you analyze in layers, the peer UA can expose to the SIP UA any 
functionality it wants. For example, the peer UA can provide the SIP UA 
with one big ALG, provide STUN relay functions, or even expose a virtual 
non-NATed routing environment and removing any NAT issues. The local 
peer component can even provide the local SIP UA with a registrar 
functionality.

I'm not saying that this is the way it should be implemented (the drafts 
have of course progressed deeper into implementations, and I may be 
behind here; however, I haven't found this discussion anywhere and I 
don't see it in the drafts or discussions). I'm just saying that talking 
about NAT handling in the p2p protocol as if it was the same problem as 
in SIP may prevent us from seeing some other ways of solving this. In 
fact, I'm still not decided on which implementation approach I favor.  
However, IMHO, I think the only way to secure widespread adoption of 
p2psip is to make sure that the SIP implementors can take a quick look 
at the spec and see where the SIP UA or proxy needs new functionality, 
and that p2psip functionality is deeply woven into the SIP stack (and 
that doesn't mean that the p2p peer functionality cannot leverage the 
SIP stack for its own functionality...)

I'll try to elaborate further in my reply to David in this thread.
g-)

---

From: "Greger V. Teigre" <[email-masked]>
Date: Wed, 27 Jun 2007 12:04:17 +0200

> * The two layers are completely independent
Thanks, good summary. My point is that it seems that NAT handling for 
p2p networks and SIP are different enough to justify a separate analysis 
(I think draft-matthews-p2psip-nats-and-overlays-01 does a good job 
there). My interpretation is that the type of p2p network has also an 
impact on NAT handling. So, using SIP concepts to solve NAT in p2p 
networks seems to me as a classic "if you have a hammer..." case.
> traversal on the SIP side...)
What a relief! ;-)
> two times for the two protocols. 
Well, ICE is clearly not the answer to all the NAT issues. ICE is about 
detecting, while NAT has detection element, a routing element, as well 
as a traversal complexity element (i.e. ALG/firewalls). It is made for 
offer/answer protocols and is suitable to solve NAT from that point of view.

draft-matthews-p2psip-hip-hop-00 offers an alternative where NAT 
traversal is handled transparently. Deep in that draft and in the 
references, there is something interesting found (from the 
"analyze-in-layers" perspective"). Let me try to pull it forward and 
summarize from a NAT perspective (for the sake of discussion):

IPsec has over the years had a lot of trouble with NAT traversal and 
ALGs. It has gone through all the pains and with UDP-encapsulation, 
NAT-T and port floating to port 4500, it has by now fairly good NAT 
traversal characteristics. Let's say each peer establishes IPsec tunnels 
with each peer, using their certificates in IKE, and calculating a 
virtual IP address (peerID). We know IPsec mostly as a network stack 
protocol, but why not implement it on the application layer? (ref. 
ongoing draft-nikander-esp-beet-mode-07)

Implement p2p routing on top of it (HIP, dSIP, whatever you like), using 
the peerID/IP address, and you have a virtual network between all peers, 
all can establish tunnels with each other (and maybe negotiate dht to 
use etc), the p2p layer can provide the SIP UA with a non-NATed network. 
All signaling is secured and relaying can easily be offered as a service 
to the SIP layer.

The benefit of layering is that you can reuse existing software 
implementations directly, you leverage years of NAT traversal 
experience, and you avoid that p2psip enabling of existing UAs turns 
into a large software implementation project with lots of uncertain 
characteristics.

This is NOT intended as an argument in favor of hip-hop vs. dSIP, rather 
an example to show why I don't like the NAT discussion to be preempted 
as "ice will be the choice anyway." I'm afraid it will prevent us from 
looking at other approaches (or reducing ice to the subset we really need).

> This group is about making a protocol
> most sense. 
Is that a shared understanding? It seems to me that there is a push to 
make it usable in non-SIP scenarios as well?
> There may be an IETF group to do more generic P2P someday
Yes, I'm sorry, the API example was confusing. I was trying to emphasize 
the possibility that we don't have a p2p aware SIP UA and a SIP-aware 
p2p client, and that trying to keep them apart would be good from an 
analysis point of view, because doing so may give us better answers than 
keeping both p2p and SIP in our heads at the same time.
g-)

---

From: Philip Matthews <[email-masked]>
Date: Thu, 28 Jun 2007 05:52:21 -0400

On 27-Jun-07, at 06:04 , Greger V. Teigre wrote:
> Well, ICE is clearly not the answer to all the NAT issues. ICE is  
> about detecting, while NAT has detection element, a routing  
> element, as well as a traversal complexity element (i.e. ALG/ 
> firewalls). It is made for offer/answer protocols and is suitable  
> to solve NAT from that point of view.
>
> references, there is something interesting found (from the "analyze- 
> in-layers" perspective"). Let me try to pull it forward and  
> IPsec has over the years had a lot of trouble with NAT traversal  
> and ALGs. It has gone through all the pains and with UDP- 
> encapsulation, NAT-T and port floating to port 4500, it has by now  
> fairly good NAT traversal characteristics. Let's say each peer  
> establishes IPsec tunnels with each peer, using their certificates  
> in IKE, and calculating a virtual IP address (peerID). We know  
> IPsec mostly as a network stack protocol, but why not implement it  
> on the application layer? (ref. ongoing draft-nikander-esp-beet- 
> mode-07)
>
> Implement p2p routing on top of it (HIP, dSIP, whatever you like),  
> using the peerID/IP address, and you have a virtual network between  
> all peers, all can establiFrom [email-masked] Thu Jun 28 07:06:03 2007
From: Philip Matthews <[email-masked]>
Subject: Re: [P2PSIP] Trying to grasp what we really are standardizing...
Date: Thu, 28 Jun 2007 05:52:21 -0400
To: Greger V. Teigre <[email-masked]>
Cc: P2PSIP Mailing List <[email-masked]>

On 27-Jun-07, at 06:04 , Greger V. Teigre wrote:
> Well, ICE is clearly not the answer to all the NAT issues. ICE is  
> about detecting, while NAT has detection element, a routing  
> element, as well as a traversal complexity element (i.e. ALG/ 
> firewalls). It is made for offer/answer protocols and is suitable  
> to solve NAT from that point of view.
>
> references, there is something interesting found (from the "analyze- 
> in-layers" perspective"). Let me try to pull it forward and  
> IPsec has over the years had a lot of trouble with NAT traversal  
> and ALGs. It has gone through all the pains and with UDP- 
> encapsulation, NAT-T and port floating to port 4500, it has by now  
> fairly good NAT traversal characteristics. Let's say each peer  
> establishes IPsec tunnels with each peer, using their certificates  
> in IKE, and calculating a virtual IP address (peerID). We know  
> IPsec mostly as a network stack protocol, but why not implement it  
> on the application layer? (ref. ongoing draft-nikander-esp-beet- 
> mode-07)
>
> Implement p2p routing on top of it (HIP, dSIP, whatever you like),  
> using the peerID/IP address, and you have a virtual network between  
> all peers, all can establish tunnels with each other (and maybe  
> negotiate dht to use etc), the p2p layer can provide the SIP UA  
> with a non-NATed network. All signaling is secured and relaying can  
> easily be offered as a service to the SIP layer.
>
> experience, and you avoid that p2psip enabling of existing UAs  
> turns into a large software implementation project with lots of  
> uncertain characteristics.
>
> This is NOT intended as an argument in favor of hip-hop vs. dSIP,  
> rather an example to show why I don't like the NAT discussion to be  
> preempted as "ice will be the choice anyway." I'm afraid it will  
> prevent us from looking at other approaches (or reducing ice to the  
> subset we really need).

I agree with much of what you said above.
However, I would like to make a comment.

Even if we push NAT traversal down to a lower layer (as you mention,  
and as draft-matthews-p2psip-hip-hop proposes), there is still the  
question of how the connections at that layer are established.
I think they will use something very ICE-like. It may not be exactly  
ICE, because ICE is officially an extension of SDP, but if we extract  
out the basic concepts, they are independent of SDP or SIP.
There ARE totally different approaches: MIDCOM or Microsoft's  
Universal Plug-n-Play (UPnP), for example (and there are others). But  
right now, none of these different approaches look very compelling to  
me.

- Philip