Subject: [P2PSIP] new draft: draft-zangrilli-p2psip-whysip-00

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 13 Mar 2007 19:00:00 -0400

There has been some recent traffic on the list and in some of the
drafts about the choice of sip or not-sip as the Peer Protocol for
p2psip.  Marcia and I thought that we would try to organize our
thoughts on why SIP is the right choice for a Peer Protocol and to
address some of the concerns that have been expressed about it.  (We
refer directly to draft-baset-p2psip-p2pcommon-01, which seems to
present a good organized list of concerns about SIP as the Peer
Protocol.)

We have submitted the draft to the editor, but obviously it won't be
posted until after IETF68 begins.  In the meantime, you can find it
at:

http://www.sipeerior.com/tmp/draft-zangrilli-p2psip-whysip-00.txt
and
http://www.sipeerior.com/tmp/draft-zangrilli-p2psip-whysip-00.html

Also, as it is late, we won't request any agenda time for it, but we
felt it would be useful to discuss on the list and in hallways at
Prague.

Bruce

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Dean Willis <[email-masked]>
Date: Tue, 13 Mar 2007 20:06:46 -0500

> present a good organized list of concerns about SIP as the Peer

My major concern is that SIP-as-it-exists is complicated and makes my  
head hurt. It also fails to address the transited-node security  
problem, which is a major problem in some P2P architectures (where  
random peers get to fondle your message as it goes by).

The sipsec: model does seem to fix this security problem, and if were  
adopted exclusively, might well fix some of the other complexity  
issues (like switching from UDP to TCP on command so that you can  
receive a large MESSAGE).

--
Dean

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 14 Mar 2007 09:23:07 -0600

Dean Willis wrote:
> adopted exclusively, might well fix some of the other complexity  issues 
> (like switching from UDP to TCP on command so that you can  receive a 
> large MESSAGE).

Regarding sipsec, the old I-D has since expired, but is archived
at http://tools.ietf.org/html/draft-gurbani-sip-sipsec-00.

I wanted to get a revision out before Prague, but (unfortunately)
my day job took precedence.  I will have a revision out shortly
after Prague meeting for a more focused discussion now that we've
had some implementation experience with it as well.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 Mar 2007 17:30:52 -0400

I think this is a point worth spending some time on.

We can take the position that we want as many EXISTING sip clients to be
conforming p2psip clients, in which case we probably don't want to have any
restrictions on those clients.  If they are 3261 compliant, they are p2psip
compliant.  We could require some other RFCs if all or at least most
EXISTING sip clients did them.

If we step off that particular bandwagon and say "oh, no, actually, we need
this teeny weenie change in your SIP client", then Dean, and several of us
would like to say if you aren't going to take a sip client as-is, then we
would like to say more than a few things about the p2psip client.  Things
like:
No forking
No UDP
No early media

And a few choice others.  Probably deletions only, nothing new.

PLEASE do not whine to me about how little work your teeny weenie change is
to the existing client.  I think that either sip, as is, is the client
protocol, or it isn't.  If it isn't, then we have some things to say...

I suspect that we'll end up with sip, as is, is the client protocol.  More
is the pity, but it's probably where we will end up.  I'd like a chance to
make p2psip more appropriate to the problem at hand, and less dependent on
the problem of compatibility to the PSTN and a few mistakes made early
before we knew better.

Brian

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, March 13, 2007 9:07 PM
> To: Bruce Lowekamp
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] new draft: draft-zangrilli-p2psip-whysip-00
> 
>

---

From: "Eric Cooper" <[email-masked]>
Date: Thu, 15 Mar 2007 12:40:05 -0400

I believe this draft is proposing that SIP is a good choice for the Peer protocol.  Forgive me if I'm wrong, but I don't think it says anything about the Client protocol (or even if Clients exist).  I'm using the term "Clients" as described in the concepts draft.

SIP may have a bunch of baggage that people would like to deprecate and perhaps we could leave some of it out if/when SIP is used as a Peer protocol (I'm thinking UDP support), but I don't know that we can do anything about early media.  Media is not really what the peer protocol is about.  It's about user/resource location.

It sounds like you're interested in SIP 3.0, but I don't think this WG is really the vehicle for that, since our charter says that "Session management, messaging, and presence functions are performed using conventional SIP".

I do think it would be great if we could get existing 3261 UAs to access the user/resource location service of P2PSIP.  We could do this by 

1) coupling a P2PSIP Peer with a 3261 Proxy/Registrar; and/or
2) adding a P2PSIP Client to an existing 3261 UA.

I personally prefer option 1, but even if we select option 2, *and* we decide that SIP is a good P2PSIP Client protocol, that doesn't mean that we can do anything about the 3261 usage of SIP for making VoIP calls.  Note that it's possible to select option 2 without using SIP as the Client protocol.  I believe http://tools.ietf.org/wg/sip/draft-singh-p2p-sip-01.txt proposes something like option 2.  In this case, would you and Dean also advocate changes to SIP?

Best Regards,

Eric.

---

From: "Enrico Marocco" <[email-masked]>
Date: Thu, 15 Mar 2007 17:56:13 +0100

Dean Willis wrote:
> head hurt. It also fails to address the transited-node security problem,
> which is a major problem in some P2P architectures (where random peers
> get to fondle your message as it goes by).
> 

Before this thread started as "using SIP for the _peer_ protocol"
degenerates in "what a monster SIP has become", I would like to
highlight the good point Dean made about the peer protocol: whether it
is SIP-based or not, do we really want it to address the "transited node
security problem"?

I mean, while the need to secure end-to-end SIP sessions in environments
where the intermediaries cannot be trusted is pretty intuitive, does it
really make sense to require peer-to-peer security for connections using
the peer protocol for performing DHT operations?

-- 
Ciao,
Enrico

Ahem.. Sorry, the notice below is not my fault :-(
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: EdPimentl <[email-masked]>
Date: Thu, 15 Mar 2007 14:04:16 -0400

Here is how I see it.

                        P2PSIP----<builtin SIP 3261>----SIPCLIENT
                             |
                             |
                             -----------------P2PSIP (other compliant DHT
overlay)

-E

On 3/15/07, Eric Cooper <[email-masked]> wrote:
>
> I believe this draft is proposing that SIP is a good choice for the Peer
> protocol.  Forgive me if I'm wrong, but I don't think it says anything about
> the Client protocol (or even if Clients exist).  I'm using the term
> "Clients" as described in the concepts draft.
>
> SIP may have a bunch of baggage that people would like to deprecate and
> perhaps we could leave some of it out if/when SIP is used as a Peer protocol
> (I'm thinking UDP support), but I don't know that we can do anything about
> early media.  Media is not really what the peer protocol is about.  It's
> about user/resource location.
>
> It sounds like you're interested in SIP 3.0, but I don't think this WG is
> really the vehicle for that, since our charter says that "Session
> management, messaging, and presence functions are performed using
> conventional SIP".
>
> I do think it would be great if we could get existing 3261 UAs to access
> the user/resource location service of P2PSIP.  We could do this by
>
> I personally prefer option 1, but even if we select option 2, *and* we
> decide that SIP is a good P2PSIP Client protocol, that doesn't mean that we
> can do anything about the 3261 usage of SIP for making VoIP calls.  Note
> that it's possible to select option 2 without using SIP as the Client
> protocol.  I believe
> http://tools.ietf.org/wg/sip/draft-singh-p2p-sip-01.txt proposes something
> like option 2.  In this case, would you and Dean also advocate changes to
> SIP?
>
> Best Regards,
>
> Eric.
>
>
>
>

---

From: Karst Bjorgson <[email-masked]>
Date: Sun, 18 Mar 2007 23:44:14 -0700 (PDT)

--- Enrico Marocco <[email-masked]>

> the peer protocol for performing DHT operations?

I think there is a natural way to partition the
problem, by looking at three phases: before a SIP
message has been exchanged between two peers, when two
peers decides to accept a SIP packet from each other,
and after that.

Before is the time for DHT, broadcast, DNS update and
what not. The problem to solve is simple: how can a
peer discover the transport coordinates of another
peer. The solutions space is rich: broadcast queries
on a single link, various DHT, even location servers.
It is probably best to assume that there will not be a
unique standard. We may want to specify a simple "must
implement" solution based on SIP, but it has better be
extremely simple.

The first exchange is interesting. Given the rich
solution space for discovery, we should assume that
the first packets are very much untrusted. They could
be spam or spoofs. The big question is how to get a
modicum of security, so the two parties can decide
that they know enough about each other and about the
channel to go on with the exchange. This is actually a
much harder problem than picking a DHT. And this is
where we probably need the most efforts, as we really
want a standard solution.

After that, we should be pretty much in the domain of
standard SIP, minus proxies. There may be a question
or two that need resolving, e.g. how to support
roaming without a fixed point, but they seem second
order.

-- Karst

____________________________________________________________________________________
Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 19 Mar 2007 01:36:41 -0700

>No early media

This is ok, can we add however:

No fast discharge of the battery in the mobile device.

This will make the list for the peer protocol look very different
probably.

Thanks, Henry

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Wednesday, March 14, 2007 10:31 PM
To: 'Dean Willis'; 'Bruce Lowekamp'
Cc: 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] new draft: draft-zangrilli-p2psip-whysip-00

We can take the position that we want as many EXISTING sip clients to be
conforming p2psip clients, in which case we probably don't want to have
any
restrictions on those clients.  If they are 3261 compliant, they are
p2psip
compliant.  We could require some other RFCs if all or at least most
EXISTING sip clients did them.

If we step off that particular bandwagon and say "oh, no, actually, we
need
this teeny weenie change in your SIP client", then Dean, and several of
us
would like to say if you aren't going to take a sip client as-is, then
we
would like to say more than a few things about the p2psip client.
Things
like:
No forking
No UDP
No early media

PLEASE do not whine to me about how little work your teeny weenie change
is
to the existing client.  I think that either sip, as is, is the client
protocol, or it isn't.  If it isn't, then we have some things to say...

I suspect that we'll end up with sip, as is, is the client protocol.
More
is the pity, but it's probably where we will end up.  I'd like a chance
to
make p2psip more appropriate to the problem at hand, and less dependent
on
the problem of compatibility to the PSTN and a few mistakes made early
before we knew better.

Brian

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 19 Mar 2007 09:55:55 +0100

I think that figuring out how we do the DHT most cleanly, and if we
have them, how we decide something should be a client (rather than a
peer) is more likely to be the biggest determining factor of battery
life. I find it pretty hard to believe that syntax choice (i.e., SIP
or not) will have much bearing on that, since the messages may be
bigger, but only by a factor of 1 or 2...reducing how often things
talk to one another to maintain the DHT or how many "fingers" they
exchange each time is likely the bigger factor there.

David

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com