Subject: [p2p-sip] Some comments on Use-cases document

From: philip_matthews at magma.ca (Philip Matthews)
Date: Mon, 20 Mar 2006 19:25:38 -0600

In advance of Wednesday's BOF session, I thought I should
send out a few comments on the use-cases document
http://www.ietf.org/internet-drafts/draft-bryan-sipping-p2p- 
usecases-00.txt

First of all, I think that having such a document is a great idea.
We can use this document to pick the use-cases that we want to support.

Some comments:

* I was initially confused when reading section 3. After reading a  
few times,
it seems to me that some of the sections describe a network type
(e.g., "global Internet" or "Limited Internet Connectivity") while  
others describe
a particular P2P use-case. I would be helpful if the document made  
the distinction
between these two types of descriptions clearer.

* I think it would be helpful to describe each use-case in more  
detail, and
make it clear how the use-cases differ from each other.

* Section 3.1.1 "Public P2P VoIP Service Providers" doesn't really  
describe
this use-case -- right now, it is mostly a few comments on Skype
(which seem out-of-place). I might suggest that this use-case could
be characterized as follows:
-      Very large numbers of peers (millions)
-      Some may be behind NATs, while others may have public IP  
addresses
-      Protection against malicious peers is very important
-      Connection to PSTN and CS SIP is important

* What is the distinction between 3.1.1 Public P2P VoIP Service  
Providers"
and 3.1.2  "Open Global P2P VoIP Network"??  Is the only difference  
the fact
that in 3.1.1, there is an organization who determines who is allowed  
to join the
overlay, while in 3.1.2, there is no such organization?

* I would like to add another use-case under 3.1 "Global Internet  
Environment".
This use-case is a IP PBX for a company which has a number of  
branches scattered
throughout the world. Each branch consists of a number of phones, and  
each branch
has a NAT or Firewall box connecting its private network to the  
Internet.
The phones in all the branches connect together into a single P2P PBX  
system.
This use-case differs from 3.4.1 because in this use-case some phones  
must
connect to each other via the Internet.

* Finally, I find calling these "use-cases" a bit strange. They seem  
much too high-level
and vague to be anything like what the term "use-case" means in UML.
I might suggest a term like "application scenarios" might be more  
appropriate.

- Philip

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 20 Mar 2006 19:19:13 -0800

I'd add to that this key question:

	"Will we extend SIP, or create a new protocol?"

I'm finding it hard to make any headway without understanding the above.
Basically, I see two major directions we could go:

1) Extend SIP with overlay-maintenance and resource-location messages.

2) Create a new overlay protocol and develop bindings for SIP and ICE (eg,
distributed proxy service and STUN/TURN resource-location service).

It seems this high-level decision keeps coming up again and again in
discussions of the smaller issues.

-david

> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-
> bounces at cs.columbia.edu] On Behalf Of Philip Matthews
> Sent: Monday, March 20, 2006 5:26 PM
> To: P2P-SIP
> Subject: [p2p-sip] Some comments on Use-cases document
> 
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 21 Mar 2006 11:02:06 -0600

> discussions of the smaller issues.

I propose that we first define an abstract model of an overlay  
network that includes the requisite primitives INSERT and QUERY  
(anything else needed?) and use this abstraction as our middle layer.

For the lower-layer, we do a binding from the abstraction to one or  
more distributed database models, probably starting with CHORD. This  
leaves our P2PSIP architecture independent of the database, but gives  
a proof-of-concept adequate for implementation.

For the upper-layer, we have one model defined using SIP REGISTER  
messages. We've also heard of work that uses REGISTER for the  
"INSERT" primitive and SUBSCRIBE/NOTIFY for the "query" primitive.

I'm also very interested in seeing if there's an obvious binding for  
TURN here, as that might kill two birds with one stone.

I propose we start with the REGISTER/REGISTER model from the bryan  
draft and talk that through a little further before we think about  
changing it.

--
Dean

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Tue, 21 Mar 2006 13:19:20 -0600

> discussions of the smaller issues.

For what it is worth, I can say that my own views on this subject  
have changed.

For all of last year, I strongly believed that there should be two  
distinct layers:
a SIP layer and a P2P layer (i.e., option 2). See the arguments I  
wrote in
   http://www.p2psip.org/drafts/draft-matthews-sipping-p2p-industrial- 
strength-00.txt
as well as those on Alan Johnston in
   http://www.p2psip.org/drafts/draft-johnston-sipping-p2p-ipcom-01.txt

However, in the last few months, I have come to see that there are  
some good reasons
to put the two layers together into one (i.e., option 1):
	a) NAT Traversal becomes easier because there is just one port,  
rather than two
	   (this assumes that the P2P layer would run on a different port  
than SIP)
	b) Possible performance improvements. With two layers, you have to  
first ask
	  "where is user U?" and then send the Invite message. With one  
layer, there is
	  the possibility of sending the Invite and having it routed to the  
user.
	  (David et al removed this from their latest draft, but this was an  
option in the
	  earlier version, and also in the work done by Henning's group).

As others have pointed out, there are also drawbacks, so I haven't  
concluded anything
yet, but I am a lot more open to option 1 than I was a few months ago.

- Philip

PS. What this has to do with the use-cases document, however, I am  
not clear on  ;-)

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Tue, 21 Mar 2006 14:41:06 -0600

resending since this hasn't been acked by the mailing list or appeared
after over 30 minutes.  (I'm sure it will now immediately appear)

On 3/21/06, Bruce Lowekamp <lowekamp at cs.wm.edu> wrote:
> I don't thnk it has anything to do with use-cases, either
>
> but
>
> Building DHT maintenance on top of SIP gives us all of the advantages
> of the routing, addressing, naming, and security issues already built
> into SIP.  Plus the NAT traversal capabilities of STUN, TURN, and ICE.
>  While not perfect for our use, I think with very minimal
> modifications (whatever the final protocol is) they will provide a
> very good solution.
>
> A proposal to use something else needs to:
> - explain what the shortcomings of SIP are for this purpose
> - explain how a new or different solution will provide equivalent functionality
> - explain how/why the new protocol will be better after resolving the
> complexities that SIP has become so complex to address
> - make a convincing enough case to justify deploying devices (and
> we're frequently talking about very small devices) to implement two
> separate protocol stacks.
>
>
> The exact DHT algorithm we implement, the exact way the we use SIP,
> the methods, etc I think are all going to need some careful thought.
> But for P2P SIP, I think SIP is the obvious choice for DHT operations,
> and I would consider it the default unless a convincing argument is
> made against it.
>
> A number of comments have been made stating that NATs must be taken
> into account from the beginning.  Again, one of the issues that using
> SIP helps address already is NAT traversal.  It's not perfect for
> signalling, but the framework is there.
>
> Bruce
>
> On 3/21/06, Philip Matthews <philip_matthews at magma.ca> wrote:

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Tue, 21 Mar 2006 14:02:05 -0600

but

Bruce

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 21 Mar 2006 13:20:18 -0800

> and I would consider it the default unless a convincing argument is

Not an argument but a question: how to efficiently implement Kademlia
STORE_VALUE primitive in SIP INVITE/REGISTER when the stored values can be
of any length and type?

peter

*** dont bash me, we are of the same country ***

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 21 Mar 2006 15:23:07 -0600

I believe that SIP is now such a monster that any attempt to P2P the SIP
protocol itself is going to be a total implementation mess.   A separate
overlay that links nicely with SIP but requires no changes to SIP/RTP/SDP
apart from understanding different naming syntaxes (ie, something not DNS or
numbers) is a lot more clean with a lot less screaming from other working
groups that are obsessed with IMS and the CSS7.

There are problems with overlays, but the problem space is being slowly
examined by people in this mailing list.

The key issues with overlays are as follows:

1. Establishment/bootstrap
2. Identity and naming
3. Persistence
4. Security

All without servers,  all working perhaps without acesss to a public
internet.  I think these can only be done via a separate overlay.   I've
done some investigation, it appears that the biggest issues
(Identity/Traversal/Persistance) are less important issues.  I'll discuss
more at the BOF and the Ad Hoc, I've not had time to get things down on
paper in internet-draft form.   Will do tho.

To change SIP to support all those things is going to be a bloody
nightmare.  A smart lean overlay that sits under SIP?
Done well, the only noticed change for other working groups would be to add
a new naming scheme outside DNS and perhaps some minor changes to ICE to
support  P2PSIP namespaces and movement between P2PSIP domains and SIP
domains.  That's it.  Statewise I don't think we have any need to change ICE
requirements.

So if we want to meet the goals of the charter and to follow IETF rules we
should strongly consider SIP and the P2P overlay as different things.  If
the charter is to follow the rules of reuse, minimal changes,  and respect
the very clear statements coming from MMUSIC (which I fully respect, btw),
SIP and SIPING working groups I don't think there is a choice.

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

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Tue, 21 Mar 2006 15:30:07 -0600

Could you please point to where the nightmare occurs?  Our -02 draft
addresses most of these issues and I think extensions have been
discussed for how to implement the remaining issues, and the changes
are really minor.  It works on top of a standard stack.  Plus, since
non-dht nodes don't need to see any of the new params or headers, it
doesn't create anything that those not implementing P2PSIP need to
worry about seeing or supporting.  I don't see the nightmare.

Bruce

On 3/21/06, Michael Slavitch <slavitch at gmail.com> wrote:
> To change SIP to support all those things is going to be a bloody nightmare.

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Tue, 21 Mar 2006 15:36:59 -0600

The DHT is well-suited for storing URIs.  My thought for storing
arbitrary data (voicemail, configuration, etc) is to have the DHT
store the URI of a configuration file that is accessed via other
standard means (MSRP, etc).  That keeps the DHT as simple as possible.

Bruce

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 21 Mar 2006 13:56:56 -0800

Hi Bruce,

Thanks for sharing the thought of protocol mixing.

Unfortunately, whoever chooses Kademlia often must handle value retrieval at
the same time as key lookup. For example, FIND_VALUE implies FIND_NODE. It
is beyond my imagination to mix SIP and (eg.) MSRP in one single primitive
:-(

By the way, some overlay operations may be parallel and asynchronous. Though
much less than those in SS7, RFC 3261 defines some timers
(T1/.../A/B/C/.../K) in SIP protocol. Will P2P SIP regulate possible
asynchronous/timed activities? It seems essential for interoperability.

peter
----- Original Message -----
From: "Bruce Lowekamp" <lowekamp at cs.wm.edu>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: "Philip Matthews" <philip_matthews at magma.ca>; "P2P-SIP"
<p2p-sip at cs.columbia.edu>
Sent: Tuesday, March 21, 2006 1:36 PM
Subject: Re: [p2p-sip] Some comments on Use-cases document

Bruce

> > > >           (David et al removed this from their latest draft, but
this
> was an

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 21 Mar 2006 17:05:05 -0600

> STORE_VALUE primitive in SIP INVITE/REGISTER when the stored values  

By bounding the P2PSIP store-value primitive as a vector of  
distinguished name and contact URI.

It's not a question of what Kademlia can express, it's a question of  
what P2PSIP requires.

--
Dean

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 21 Mar 2006 17:08:43 -0600

On Mar 21, 2006, at 3:23 PM, Michael Slavitch wrote:

> I believe that SIP is now such a monster that any attempt to P2P  
> the SIP protocol itself is going to be a total implementation  
> mess.   A separate overlay that links nicely with SIP but requires  
> no changes to SIP/RTP/SDP apart from understanding different naming  
> syntaxes (ie, something not DNS or numbers) is a lot more clean  
> with a lot less screaming from other working groups that are  
> obsessed with IMS and the CSS7.
>

I don't necessarily disagree, but this after all the P2PSIP BOF we're  
talking about. If we need a P2PVOIP BOF that defines an entirely new  
protocol, draft up a charter and get some sponsoring ADs and see if  
you can get the BOF approved. If it looks like it has traction, I'll  
show up and help out.

Or maybe an OpenSkypeLike open source effort would be better. Way  
cool, but way outside the IETF's scope.

--
Dean

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Tue, 21 Mar 2006 15:50:30 -0800

pls dont give up so soon.

with original initiative in mind of and topdown+bottomup+macro+micro
viewpoints of smart people here from academical and industrial fields, ietf
can stop in time similar funny (foul) plays by some branded softswitch
vendors who approached class5 switches by heavy-weight b2bua utilizing only
basic SIP call control primitives blended with brute forces (some even relay
media between two ua's behind full-cone nat!!) when ietf has taken years of
efforts on standardizing STUN, REFER, "SIP Service Examples", ...etc.

open source (to attackers) is a no go, as i have questioned (but none
answered) earlier.

peter