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

From: jdrosen at cisco.com (Jonathan Rosenberg)
Date: Mon, 13 Mar 2006 16:41:28 -0500

David Barrett wrote:

>>-----Original Message-----
>>From: Jonathan Rosenberg [mailto:jdrosen at cisco.com]
>>Subject: Re: [p2p-sip] Problem statement for P2P SIP NAT traversal
>>
>>
>>>- Establishes direct connections with >90% effectiveness in today's
>>
>>internet
>>
>>>	. eg, include symmetric<->symmetric piercing
>>
>>I'll agree with that.
> 
> 
> Cool!  I didn't realize ICE supported this yet.

It does it with relays, of course. Thats what turn is for.

> 
> 
> 
>>>- Evaluates all routes in parallel and select the fastest
>>>	. vs sequential evaluation
>>
>>You can't have your cake and eat it too. ICE originally worked this way
>>and it was found to be hugely problematic from a congestion and nat
>>overload perspective. That is why it was changed later on.
> 
> 
> Extra cool!  Again, my understanding of ICE was out of date.

To be clear - ICE use a sequential mode. The parallel mode was 
previously in ICE and was discarded. Your requirement was for paralell. 
I am saying that I disagree with parallel because of the problems that 
were found. This had extensive discussion in mmusic.

> 
> 
> 
>>>- Discovers the minimum keepalive frequency to maintain UDP NAT mappings
>>>	. vs deferring to the application layer
>>
>>Ideally I'd agree with you; but this is profoundly hard to do without
>>more directly controlled nats.
> 
> 
> Well, I disagree here.  Just use a parallel "throwaway" connection whose
> only purpose is to discover NAT refresh times.

These are unreliable, as they change as the NAT becomes loaded, for 
example. See the behave specs for discussions on this. STUN used to 
attempt to do this timing discovery (its in rfc3489), but that whole 
nat-discovery and black-box measurement thing has been thrown away.

   I use this in iGlance and it
> works great.  With it I've discovered that NAT refresh times are horribly
> erratic, and not at all constant (I've experienced NATs that start at 1s and
> grow up to 512s over time).

Exactly. Thats why its a bad idea to try and discover it. Its going to 
change.

> I believe this is a sufficiently advanced
> problem that it should be handled by the NAT solution itself, rather than
> left up to the application developer.

The solution is to use a minimum value that works with high reliability.

> 
> 
> 
>>I also don't see what this has to do with p2p.
> 
> 
> If P2P is defined purely as DHT, then I'd agree.  But it's my understanding
> our mandate takes a broader view, including the integration of NAT
> penetration best practices.

Well, the purpose of a bof is to debate the charter. I am proposing that 
the objective of p2p sip is not a free pass to change anything in sip it 
  likes.

> 
> 
> 
>>>- Integrates with core SIP syntax (INVITE, REGISTER, etc)
>>>	. vs a standalone protocol with unique grammar
>>
>>That seems like a solution proposal and not a requirement. It also has
>>nothing to do with p2p.
> 
> 
> Well, yes, I'd suggest we not abstract NAT from SIP, just like I'd prefer we
> not abstract DHT from SIP (another topic of ongoing debate).  I don't
> dispute we *can* (ICE being a great example of the result when you do), but
> I personally think SIP can and should be extended to accomplish both.  

SIP has been extended to deal with nat traversal. That extension is ICE 
for media and sip-outbound for signaling.

> 
> As such, I'm offering this as a requirement.  I don't claim that it *is* a
> requirement (because the list doesn't yet exist, and certainly hasn't been
> formalized), but I'm happy to argue for its inclusion.
> 
> 
> 
>>I find it odd that your suggested requirements miss what I think is the
>>only new requirement here - that the solution not require a centralized
>>server in order to operate. THAT is actually a reasonable and new
>>requirement introduced by p2p.
> 
> 
> Again, I accept as reasonable the view that the *only* topic open for debate
> is how to decentralize the SIP proxy.  Personally, I take a broader view
> (and one that I believe is consistent with our mandate).

Well, like I said, the charter is up for discussion still.

You have not yet commented on the interoperability issue. I take it 
then, you have no interest in interoperability with regular sip endpoints?

> 
> 
> 
>>>I'm not totally sure how ICE and Teredo stack up against this,
>>
>>Of course you are. Please don't dance around the point. You know very
>>well from your other comments how ICE does and doesn't address these
>>points. To date, your proposals on investigating SIP p2p nat traversal
>>seem to be a thinly veiled attempt to design and/or select alternate nat
>>traversal techniques because of some grudge against what has been
>>specified already.
>>
>>As I have suggested before, if you have beefs with the design of ICE,
>>take them to mmusic and lets discuss there as part of ICE discussions.
>>If you have an alternative proposal, I look forward to the draft. But,
>>it is a travesty to the community to use p2p sip as an excuse to
>>redesign parts of SIP with new requirements that have nothing to do with
>>p2p.
> 
> 
> Well, given that I was wrong on at least two points about ICE, I can say
> with certainty that I didn't know how they'd stack up.  ICE has undergone
> (and, I think, is undergoing) rapid change, and it's hard to keep up.
> 
> As for my ulterior motive, I think it's not so thinly veiled: I believe
> there are superior options to ICE and I'd like us to investigate them.

Hmm, I couldn't find your draft in the archives... must've missed it.

> You're correct, this has been my explicit goal from the start.  So far as I
> can tell, it's within our mandate to consider alternatives to ICE, and I'm
> just trying to push along that path.

I disagree, and I thank you for making it clear that you believe it is 
in the charter to reinvent whatever pieces of sip you like, including 
nat traversal, even if what we have works for p2p - just because you 
don't like them. No doubt I'll have comments on that part of the charter 
text.

> 
> That's a fair suggestion that I take my concerns to the ICE group, but given
> that I fundamentally disagree that ICE is needed at all (my point is that
> SIP should handle it implicitly), this seems like a futile gesture.

So, if I get this correctly, you are saying that, you disagree with 
ICE's design, but instead of taking that to the group where its being 
developed, you would rather start a new group to do something in 
parallel - something different - using p2p as an excuse.

Help me understand how that is in the best interests of the IETF 
community or in the best interests of interoperability.

> 
> And I appreciate your request for a drafted alternative.  If the P2P-SIP
> group lists the criteria for acceptance and commits to a fair evaluation
> based on those criteria, that's just what I (and I'm sure others) will do.

Rather than hiding behind p2p, if you've got beefs with SIPs nat 
traversal soltuions, bring em up and let the community working on them 
have a chance to review and comment.

>  
> Finally, let's keep this focused on the merits and combinations of ICE, SIP,
> P2P, DHTs, etc.  This isn't about me.

The merits of ICE belong in the mmusic list, where that community can 
provide comment.

-Jonathan R.

-- 
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