Subject: RE: [Sipping] FW: I-D ACTION:draft-johnston-sipping-p2p-ipcom-01.txt

From: "Johnston, Alan" <[email-masked]>
Date: Thu, 07 Apr 2005 04:17:28 +0100

Hi Stephen,

Thanks for your comments - see mine below.

Thanks,
Alan Johnston
sip:[email-masked]

> -----Original Message-----
> From: Stephen Sprunk [mailto:[email-masked]] 
> Sent: Tuesday, April 05, 2005 4:16 PM
> To: Johnston, Alan; sipping
> Subject: Re: [Sipping] FW: I-D 
> ACTION:draft-johnston-sipping-p2p-ipcom-01.txt
> 
> 
> Thus spake "Johnston, Alan" <[email-masked]>
> > I have updates my SIP P2P draft with some new ideas.
> >
> > Comments are, as always, greatly appreciated.
> 
> 
> I've read through the draft a couple times now and I'm still 
> scratching my head on how it improves the situation.  It 
> seems to require a new location server and a new protocol to 
> access it, but that server has effectively the same function 
> as a SIP registrar -- it's just not speaking SIP anymore.

No - today, every domain has a location server and uses some proprietary
protocol to update and access it locally.  Standardizing such a protocol
would be a useful thing in my opinion.

> 
> Also, any UAC that didn't implement the new protocol would be 
> required to have an outbound proxy that does, potentially 
> changing the triangle back into a trapezoid.

There are two distinct levels of interaction with the location server
that I think the draft does not delineate clearly enough.  To write URIs
into the P2P network, the peer has to be the authorized registrar for
the domain - in general this will be a server, but for a small
namespace, it is possible a peer/endpoint could act as its own registrar
and perform this function.  On the other hand, the ability to query URIs
from the P2P network is something that any server, any UA could do.  It
is this function that can reduce the trapezoid to a triangle, or a
triangle to a line.

> 
> Now, if the location service were actually some p2p protocol 
> that doesn't require a fixed server, that's interesting, but 
> are there any such protocols (even in academia) that are 
> secure, reliable, and offer instant global updates with tens 
> of millions of intermittent nodes?

That is an excellent question, and one I hope this draft motivates some
people to investigate and find out.  There are a number of published P2P
protocols that use a variety of RPC mechanisms - Chord is one example.
If we agree that standardizing a location service protocol is good
thing, then I further hope that we can implement the protocol using an
existing P2P protocol as a starting point.

> 
> People have accepted that email is a trapezoid (most common) 
> or triangle in almost all cases; given how successful email 
> is, why do we think that's not good enough for SIP?  SIP 
> already improves on email by having one protocol for all legs 
> versus a mish-mash of SMTP, POP, IMAP, and HTTP.

Sure - SIP is better, but to get maximum security, reliability, and
scalability, SIP needs to be free of intermediaries.   The trapezoid
nature of email is making it difficult to react to and deal with issues
such as spam - I'd suggest we should try to avoid this trap from the
start with SIP. 

> 
> S
> 
> Stephen Sprunk      "Those people who think they know everything
> CCIE #3723         are a great annoyance to those of us who do."
> K5SSS                                             --Isaac Asimov
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 7 Apr 2005 11:09:07 -0500

> No - today, every domain has a location server and uses some
> proprietary protocol to update and access it locally.
> Standardizing such a protocol would be a useful thing in my
> opinion.

If you accept that trusted registrar servers will exist, then standardizing
the protocol between the registrar and the location server (assuming there
is one) doesn't seem to help.  Doing so would reduce the flexibility of
registrars to use the protocol that best suits their needs, meaning many
would not use a standard protocol -- nor would any UAs need to know or care
if they did.  Just use the existing SIP model and ignore what's behind the
curtain.

> There are two distinct levels of interaction with the location
> server that I think the draft does not delineate clearly enough.
> To write URIs into the P2P network, the peer has to be the
> authorized registrar for the domain - in general this will be a
> server, but for a small namespace, it is possible a peer/endpoint
> could act as its own registrar and perform this function.
> On the other hand, the ability to query URIs from the P2P network
> is something that any server, any UA could do.  It is this function
> that can reduce the trapezoid to a triangle, or a triangle to a line.

If you want a world without registrar servers, then all UACs will need to
use that protocol to access the location database or use a proxy that does.
 IMHO, this doesn't seem to be an improvement over the former _unless_ the
location database is p2p itself (something not obvious from the draft).  See
below.

> That is an excellent question, and one I hope this draft motivates
> some people to investigate and find out.  There are a number of
> published P2P protocols that use a variety of RPC mechanisms
> - Chord is one example.

I'm leery of "let's standardize every part of this model except the one
crucial piece nobody has invented yet."

I've looked into some presentations on Chord, and it appears to be an
academic exercise at the moment, though it is promising and perhaps even
useful today within a small group of stable nodes.  It's nowhere near ready
to handle millions of nodes that pop on and off the network every few
minutes.  Security isn't even mentioned, and replication is an afterthought.

> existing P2P protocol as a starting point.

So there would be two location protocols, one for registrars and one for p2p
operation?  Or are you expecting fixed registrars to use p2p networks of one
or two nodes?  Or would all registrars share a p2p network so they'd never
actually get requests -- they'd be handled by the UAC or outbound proxy?

> scalability, SIP needs to be free of intermediaries.

Proxy and registrar servers offer better security and reliability than any
existing p2p network.  Scalability is questionable; existing p2p networks
are scalable in the sense they move huge amounts of static data, but SIP has
very tiny amounts of highly dynamic data.  The state of the art right now is
that trusted servers are better at that sort of thing.

> The trapezoid nature of email is making it difficult to react to and
> deal with issues such as spam - I'd suggest we should try to avoid
> this trap from the start with SIP.

I don't see how someone spamming my phone directly is any better than
someone spamming my email server indirectly.  If anything, the server may do
a better job because it has inherent visibility into what many users are
receiving, while a phone needs a p2p network (which doesn't exist yet) of
spam signatures to get the same visibility.

Perhaps I can't "think outside the box" here, but I'm perfectly happy
running a registrar server for my domain (or paying someone else to) and
having my phone register to that.  The concern I have is most existing
deployments are walled gardens that can't speak SIP to the public Internet
or even to each other.  IMHO, that is a Layer 8 problem, not a SIP problem.

S