Subject: [p2p-sip] Problem statement for P2P SIP NAT traversal

From: jdrosen at cisco.com (Jonathan Rosenberg)
Date: Mon, 13 Mar 2006 02:20:46 -0500

I think the burden of proof would be to demonstrate that ICE cannot and 
doesn't, for some reason, work for p2p SIP.

ICE, as you may know, is itself a p2p nat traversal technique. Its 
efficacy is predicated on both sides supporting it. Thus, if we want 
interop between normal SIP clients and p2p sip clients, NAT traversal 
for everyone needs to be ICE based for things to work well.

This, of course, applies to lots of other things that sip does, which 
require endpoint support. If you are going to start throwing all of that 
away and defining new variants of sip extensions and features for p2p 
clients, you should drop the 'sip' part, and recognize that you are 
defining a new non-sip protocol for p2p. That would be a terrible travesty.

-Jonathan R.

David Barrett wrote:
>>-----Original Message-----
>>From: Juergen Quittek
>>Sent: Wednesday, March 08, 2006 3:27 AM
>>To: Martin Stiemerling; Jonathan Rosenberg
>>Cc: P2P-SIP
>>Subject: Re: [p2p-sip] Problem statement for P2P SIP NAT traversal
>>
>>
>>>>Secondly, the draft says its an analysis of existing nat traversal
>>>>techniques for sip. However, it omits the main SIP nat traversal
>>>>techinque in its entirety - ICE and sip-outbound. I dont know how an
>>>>analysis of the applicability of existing nat traversal techniques can
>>>>be considered complete when it has missed the main standards in
>>>>this area.
>>>
>>>Granted. We have missed ICE, even though it is well-known. This is not
>>>because of ignorance but due to a very fast approaching -00 deadline.
>>>As said above, the document's intention is not to open the box for a
>>>new protocols, but to explorer the existing NAT traversal space.
>>
>>Yes, the lack of ICE coverage is really a flaw.  But it should be no
>>problem to fix it for the next version.  Also, I do not see a big impact
>>on the identified issues that we should take care of when developing
>>P2P SIP.
> 
> 
> My impression was that we would define what we need from NAT traversal, and
> then evaluate all the options (ICE included).  Furthermore, once our
> requirements are specified, I thought we were going to remain option to new
> NAT traversal options, and not presuppose ICE as the final choice (otherwise
> we should just pick it now).
> 
> For example, would we be open to the following chain of events?
> 
> 1) We publish what P2P-SIP requires in the way of NAT traversal
> 2) Somebody invents a protocol that meets these requirements
> 3) We adopt this new protocol, despite it not being ICE
> 
> If we're not, then let's just say "P2P-SIP will use ICE" and be done with
> it.  Granted, I believe that'd be a mistake, but I respect that reasonable
> minds can disagree on this point.
> 
> -david
> 

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

---

From: dbarrett at quinthar.com (David Barrett)
Date: Sun, 12 Mar 2006 23:31:44 -0800

> From: Jonathan Rosenberg [mailto:jdrosen at cisco.com]

That's fair.  Let's first define what 'works for P2P-SIP' is, then we can
have a productive discussion on this point.  Specifically, I mean we should
define the NAT-traversal requirements of P2P-SIP without regard to a
solution (eg, without presupposing ICE), and then evaluate whether and to
what degree ICE meets these requirements.

Clearly, if ICE is the best solution, let's take it.  But if ICE isn't the
best solution, let's not take it, and instead find what is.  

I'm sorry, I didn't mean to present this as something new; I thought this
was already the consensus.

-david

---

From: jdrosen at cisco.com (Jonathan Rosenberg)
Date: Mon, 13 Mar 2006 12:50:18 -0500

Eunsoo Shim wrote:

> In principle, working out requirements and looking for a solution 
> without presupposing a solution are all fair. Nevertheless, I think we 
> should pay attention to existing solutions first.
> 
> As shown in our draft (draft-shim-sipping-p2p-arch-00.txt), I envision 
> that P2P SIP is composed of two layers: the P2P overlay layer and SIP. 
> In this architecture, the main difference between the P2P SIP and the 
> client server SIP is how locations of resources are identified. In a 
> sense, what we are touching in the SIP spec for P2P SIP is RFC 3263 as 
> mentioned by Henning, Kundan and others before. I don't see much 
> difference betwee the P2P SIP and the client server SIP regarding NAT 
> traversal.

Right - the main difference should be location of resources. In the case 
of ICE, the problem is how to locate STUN and TURN servers on the p2p 
network. Whats interesting with this is that ANY stun server will do; 
with a relay you'd ideally like one close by. Be interesting to see how 
that can best be done. But once you've got one, regular ICE and SIP 
should work.

-Jonathan R.

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 13 Mar 2006 11:35:45 -0800

> From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com]

Certainly.  But there are many "existing solutions".  Even if we stick
within the bounds of IETF there are at least two serious contenders: ICE and
Teredo (RFC 4380).  And if we look further afield I know of at least two
others (and I'm sure there are more).  But unless we make a serious effort
to evaluate ICE alternatives, we're not making a serious effort to evaluate
ICE alternatives.  So the question is:

"Are we going to make a serious effort to evaluate alternatives to ICE?"

If the answer is no, then let's state as much.  It certainly simplifies our
work.  This seems to be Jonathan's suggestion, and it's an entirely
reasonable approach (though not the one I recommend).

But if the answer is yes, then let's do it.  Let's state what the criteria
for selection are, and take the best option.  If ICE comes out on top,
wonderful, we can defend our choice as not only convenient but optimal.  And
if we can do better than ICE, wonderful, who wouldn't want this?

I'd just like to know if we're even considering anything other than ICE, and
what the grounds for consideration are.  It was my impression that a
discussion on this topic on this list had already occurred (late Jan) and
this plan (defining the NAT-traversal requirements before choosing a
solution) was the result [1]. 

----------------------------------------------------------------------------
[1] https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-January/000366.html

Specifically, the working group will:

...

5. Select firewall/NAT traversal technique(s) for P2P SIP and integrate
    them into the P2P SIP architecture or framework.  If necessary,
    define requirements for enhancements of existing techniques to be
    acted on by other working groups.

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

My contribution to these requirements (if we choose to have them) would be:

- Establishes direct connections with >90% effectiveness in today's internet
	. eg, include symmetric<->symmetric piercing
- Evaluates all routes in parallel and select the fastest
	. vs sequential evaluation
- Discovers the minimum keepalive frequency to maintain UDP NAT mappings
	. vs deferring to the application layer
- Integrates with core SIP syntax (INVITE, REGISTER, etc)
	. vs a standalone protocol with unique grammar

I'm not totally sure how ICE and Teredo stack up against this, nor am I sure
what the final stack of criteria should be.  Thus I'm just not sure ICE is
sufficient because "sufficient" hasn't been defined.

So in order to make headway in this discussion I'd like to know:

a) Are we going to make a serious effort to evaluate alternatives to ICE?
b) What are the criteria whereby we'll make our selection?

-david