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

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 13 Mar 2006 18:10:49 -0500

I appreciate the importance of NAT traversal for P2P SIP and respect all 
the discussions about what ICE can, cannot, should or should not do.
Whatever P2P SIP is, if the software does not do NAT traversal very 
well, it won't be adopted for a large scale use over the Internet.

But this group is not the right community to talk about all the aspects 
of ICE since ICE is a work at MMUSIC.
As all understand, we cannot simply start redesigning things other WGs 
have been working on.

However, if P2P SIP brings about any new requirement for NAT traversal 
or for ICE (,STUN,TURN, sip-outbound, etc.), I think it is appropriate 
to talk about it with the purpose of submitting the requirement to the 
appropriate WG. Certainly such requirement is not something like "we 
need a standard right now" or "a particular solution does not work 
regardless of P2P SIP."

If we see major problems with things under the charters of other WGs and 
we need fix for the problems even though the problems are not specific 
to P2P (SIP), then we should join the appropriate WGs and work out 
solutions there. I would be happy to join such efforts.

Thanks.

Eunsoo

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.
>
>
>  
>
>>>- 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.
>
>
>  
>
>>>- 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.  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).  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.
>
>
>  
>
>>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.
>
>
>  
>
>>>- 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.  
>
>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).
>
>
>  
>
>>>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.
>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.
>
>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.
>
>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.
> 
>Finally, let's keep this focused on the merits and combinations of ICE, SIP,
>P2P, DHTs, etc.  This isn't about me.
>
>
>Anyway, ultimately the P2P-SIP group will recommend best practices and
>standards for deploying SIP in internet-wide, (mostly?) serverless
>scenarios.  One component of this is NAT penetration.  One proposal is to
>just say "we recommend ICE" and be done with it.  My proposal is to define
>what criteria we'll use to evaluate NAT penetration proposals, and then
>judge the options accordingly.
>
>Which proposal do you (ie, everyone else) prefer?
>
>-david
>
>  
>