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

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Mon, 13 Mar 2006 22:34:43 -0500

Mike:
 
Just some word-smithing. How about: Peer-to-Peer Overlay Networking Protocol
(P2P-ONP)?
 
BR/Radhika

  _____  

From: Michael Slavitch [mailto:slavitch at gmail.com]
Sent: Mon 3/13/2006 9:39 PM
To: Roy, Radhika R.
Cc: Eunsoo Shim; David Barrett; P2P-SIP
Subject: Re: [p2p-sip] Problem statement for P2P SIP NAT traversal

P2PSIP may be the wrong name for the WG.  I don't have a better one but it's
more P2P than it is pure SIP. 

In fact what I keep on hearing is that changing SIP is verboten. So, let's
not do that any more than we have to.  If the complaint is "don't mess with
SIP", then "don't mess with SIP".   Message heard.  Live within what can be
construed as legitimate constraints. 

Let me come up with yet another new buzzword/acronym. If you're not fond of
it I don't mind.

Peer To Peer Overlay With Address Overloading:  P2POAO

Advantages: 

1.   Overlay is abstracted from application and protocol. SIP et al  sit on
top of OAO.
2.   Changes to SIP/SDP/RTP involve only AO  (recognizing overlay
addresses), which is 
      nomenclature. One example of an overlay address could be a CERT-like
numeric string. 
      In fact it is probably the best overlay address. Globally unique
identifiers with real   
      certified identity.
3.   These changes do not alter state nor existing functionality of existing
standards. 
4.   They are additions to, not changes to, existing protocols. Old still
works with new.
5.   Overlay NAT traversal is still needed, but need not be offer/answer.
6.   If offer/answer is needed ICE would be the IETF preference.. 
7.   If ICE can't support the overlay,  then request changes to ICE.
8.   If ICE can't or won't be changed to support the overlay, don't use
offer/answer.
9.   Offer/answer is not really needed if bootstrap can be seeded out of
band. 
10. Once bootstrap is taken care of there is a wealth of choices.

For offer answer the answer that is insisted upon looks to be ICE. 
But if it isn't offer-answer there are a wealth of things to draw upon, 

The advantage is that there are a whole number of overlay schemes that would
work well in such an OAO environment. I do not know which one is best for
P2PSIP, but I have my personal preferences that I can argue later.  But that
preference is not religious, it just has to work. First we have to decide if
the overlay and SIP should be separate entities. 

Given "don't change SIP"  there is no other way to go forward. There is no
other choice, so the choice is easy.

Now:

STUN-like things may still be needed, as a protocol that assists discovery. 

TURN-like things (might as well be TURN-derived) could supply super node
services.
(In fact, they could be only self-organizing self-advertising
overlay-addressed versions of STUN and TURN) 

ICE would still be used by SIP over P2POAO  if the overlay translates the
addresses transparently. This may well be the only requirement change for
ICE: 

1.  to recognize overlay addressing as legitimate.
2.  to accept substitutions from the overlay, make it the canonical source
of real addresses.
3.  to move from 'overlay' addressing to 'real' and vice-versa using the
overlay as a reference. 

That's about it.  Everything else in ICE would remain the same.  We may be
able to live with that.

Nothing apart from some basic housekeeping would change for MMUSIC, SIP,
SIPING amongst others. (an investigation would be needed to make sure this
is true). 

The rest  of the work would belong in P2PSIP (or P2POAO or whatever it
really is).
Perhaps it's the "SIP" part of the name that causes kerfuffles, so if so,
name it something else.  Perhaps.

So, if the insistence is "don't change SIP"  and "for offer/answer NAT
traversal use ICE" the answer well may be: 

1. Don't change SIP (apart from name support).
2. If ICE doesn't work for P2PSIP overlay offer/answer don't use
offer/answer in the overlay.
3. Given that offer/answer would bot be used by the overlay look for
alternatives and their traversal methods that are hence wise appropriate. 
4. Allow non-ICE SIP UA systems to use the overlay as a tunnel in the place
of ICE.

I am not sure how this could step on toes. If ICE is an algorithm for
offer/answer protocols then not using ICE for protocols that are not based
on offer-answer should not be a problem. 

If it still is, we're talking religion, not technology, and that means there
is no desire for a solution to the problem.

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Mon, 13 Mar 2006 22:51:05 -0500

Sure.  That sounds more IETF. Fits with the religion.  Thank you.

We're naming a baby.  From where my parents come from this is a serious
business:

1. Don't piss anyone off.
2. Don't confuse them.
3. It must be pronounced in the native dialect and not seem too exotic.
4. It must be accepted by the rabbis or priests or shamans.
5. It must respect community elders.

Requirements of a name?

1. Say what it is.
2. Do what it says.

Are we doing SIP? Probably not.
Are we doing overlays? Yup.
Are we going to address them somehow that allows us to traverse networks and
protocols? If we want to build something more than a toy: yes.

Is it peer to peer? Yup.

P2P is the surname, which, like in certain traditions, goes first.

P2PONP?  Good.  Let's poll for alternatives, but I like it. Personally I
like mine, but P2PONP is more IETF-ish. I don't care as long as it meets the
requirements above.

OAO would be a nickname, then. Which, when you think a little, is exactly
what OAO is, a very pedantic and accurate nickname mechanism, globally
unique and assured.

What kind of nickname will be the next interesting discussion.  If we get to
that point we've entered  a process of problem reduction, not process
thrash.

M

--
Michael Slavitch
Ottawa, Ontario Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060313/9b280fe8/attachment-0001.html

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 14 Mar 2006 00:30:38 -0600

On Mar 13, 2006, at 9:51 PM, Michael Slavitch wrote:

>
> P2PONP?  Good.  Let's poll for alternatives, but I like it.  
> Personally I like mine, but P2PONP is more IETF-ish. I don't care  
> as long as it meets the requirements above.
>

I'm struggling to find something that could use the acronym P2PONY.  
How about P2PONI? "Peer 2 Peer Overlay Naming for Internet"  . . .  
Maybe "Peer Overlay Naming for Internet Element Signaling", PONIES.  
It has, well, spirit.

A good catchy acronym nets one a world of marketing power.

But we do have to be very careful.

If we stay laser-focused on applying P2P techniques to solve the  
rendezvous problem for SIP, we have a solvable problem. If we  
generalize, we could be in a world of hurt. The lesson here -- don't  
generalize.

SIP does Offer/Answer. I think that narrows our focus for media  
negotiation to O/A. But that's not the same thing as correspondent  
discovery, which does not have to be an O/A problem.

Without generalizing we still have a couple of Big Questions:

1) Is the Insert/Search method SIP or some other protocol, and if  
some other, then what?

2) If we make our supernodes do STUN/TURN, does ICE solve our NAT  
traversal problem?

3) How do we solve routing topology security in a way that makes EKR  
happy and still works? I suppose one solution is to put all the  
supernodes into the trust domain and have all the user functions on  
ordinary nodes, but I suspect that isn't an optimal model for  
distribution of labor. Might work OK for the "self organizing proxy  
farm" use case, however.

--
Dean

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 14 Mar 2006 05:50:25 -0500

The IETF must remember it's in a marketing war not of its choosing.  It 
is in an asymmetric war and it is losing.

Dean, I very much like your questions. They are good questions that 
encourage a solution.

It is 5:45 AM here, my dogs need a walk, I need a coffee and get ready 
to catch a plane.

I cannot yet offer an intelligent answer. (I also should never pun.)

I agree with this point:   Stay focused on SIP. Don't overgeneralize.  
But don't drop potential.  Do not over-restrict.

As a WG requirement this would be translated as:

"The focus is on solving problems associated with SIP."

In other words.  Fix things for SIP.  If it works for other things LATER 
that is a bonus.  First things first.

I'm sure we're all smart enough to handle 'other things' later.  If the 
IETF can spend years jamming class-5 switching into SIP we can do 'other 
things' with p2p-oriented SIP.  Amazing things.  First make it work for SIP.

Michael

Dean Willis wrote:
>> Personally I like mine, but P2PONP is more IETF-ish. I don't care as 
>> long as it meets the requirements above.
>>
>
> Maybe "Peer Overlay Naming for Internet Element Signaling", PONIES. It 
> has, well, spirit.
>
> 1) Is the Insert/Search method SIP or some other protocol, and if some 
> other, then what?
>

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Tue, 14 Mar 2006 10:16:08 -0500

Hi Michael,

I'm agreeing with you here.

> is in an asymmetric war and it is losing.

I understand where you're coming from, but the idealist in me
sees the current phase as an opportunity rather than a threat.

> I cannot yet offer an intelligent answer. (I also should never pun.)

Indeed.

> But don't drop potential.  Do not over-restrict.

Right.  We've got a "distributed naming and lookup" problem to
solve.

This doesn't mean the ideas aren't more general,
but we're not tasked with making a file-sharing network
nor with replacing DNS.

We're here to establish end-to-end real time sessions between
hosts, and to connect Client/Server SIP systems to P2P systems,
even through NATs.

That's the whole box and dice.

We'll certainly have enough on our plate that even with a concerted
effort to work together and choose an acceptable (rather than best)
solution, we've still got a long, hard (but rewarding) road ahead.

Greg